On Sunday, 26 May 2019 at 16:39:53 UTC, Manu wrote:
> On Sun, May 26, 2019 at 4:10 AM NaN via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> What? ... this thread is bizarre.
>
> Why would a high quality SVG renderer decide to limit to 16x AA? Are
> you suggesting that they use hardware super-sampling to render the
> SVG?

They do both super-sampling and multi-sampling.

https://developer.nvidia.com/nv-path-rendering


> Why would you use SSAA to render an SVG that way?
> I can't speak for their implementation, which you can only possible
> speculate upon if you read the source code... but I would; for each
> pixel, calculate the distance from the line, and use that as the
> falloff value relative to the line weighting property.

Because "path" in vector graphics terms is not just a line with thickness, it's like a glyph, it has inside and outside areas defined by the winding rule, it could be self intersecting etc. Working out how far a pixel is from a given line doesnt tell whether you should fill the pixel or not, or by how much.

Whether a pixel should be filled or not depends on everything that has happened either to the left or the right depending on which way your processing. It's not GPU friendly apparently.

You could decompose the path into triangles which would be more GPU friendly, but that's actually quite an involved problem. To put it in perspective decomposing a glyph into triangles so the gpu can render it is probably gonna take lot longer than just rendering it on the CPU.


> How is the web browser's SVG renderer even relevant? I have absolutely no idea how this 'example' (or almost anything in this thread) could be tied to the point I made way back at the start before it went way off the rails. Just stop, it's killing me.

Somebody said browsers have been doing 2D on the GPU for years i just pointed out that it was more complicated than that. I wasn't replying to anything you said and dont really know why what i've said has got your hackles up.

On Sunday, 26 May 2019 at 17:36:20 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 26 May 2019 at 16:56:39 UTC, Ola Fosheim Grøstad wrote:
>> If the SVG renderer in the browser is relevant? Depends. SVG is animated through CSS, so the browser must be able to redraw on every frame. For some interfaces it certainly would be relevant, but I don't think Robert is aiming for that type of interface.
>
> Anyway Skia is available under a BSD license here:
>
> https://skia.org/
>
> I don't find anything on Ganesh or any other GPU backend, but maybe someone else have found something?

AFAIK Ganesh sucked and it was dropped. They use nv path rendering now.

https://developer.nvidia.com/nv-path-rendering

On Sunday, 26 May 2019 at 17:42:13 UTC, NaN wrote:
> AFAIK Ganesh sucked and it was dropped. They use nv path rendering now.
>
> https://developer.nvidia.com/nv-path-rendering

Ah, do you know if this is in Chromium as well, or is it something that is closed off to Chrome?

I also noticed that the author of the OpenVG renderer AmanithVG has a high quality software renderer in addition to the GPU renderer.

On Sunday, 26 May 2019 at 17:41:01 UTC, NaN wrote:
> On Sunday, 26 May 2019 at 16:39:53 UTC, Manu wrote:
>> On Sun, May 26, 2019 at 4:10 AM NaN via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>>
>> What? ... this thread is bizarre.
>>
>> Why would a high quality SVG renderer decide to limit to 16x AA? Are
>> you suggesting that they use hardware super-sampling to render the
>> SVG?
>
> They do both super-sampling and multi-sampling.
>
> https://developer.nvidia.com/nv-path-rendering

Btw, skia anti-aliasing slides and doc is here:

https://skia.org/dev/design/aaa

On Sunday, 26 May 2019 at 18:37:49 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 26 May 2019 at 17:42:13 UTC, NaN wrote:
>> AFAIK Ganesh sucked and it was dropped. They use nv path rendering now.
>>
>> https://developer.nvidia.com/nv-path-rendering
>
> Ah, do you know if this is in Chromium as well, or is it something that is closed off to Chrome?

Nevermind, based on what is going on at the Skia repo they seem to implement Metal support for Skia. So I presume that means that GPU support is built into Skia.

*shrugs*

Fairly big repo… but interesting to look at.

On 5/25/19 7:23 PM, Ethan wrote:
> 
> [...]

+1 (trillion)

In my entire software career, I have yet to ever come across even one programmer without direct game engine experience who actually has anything intelligent (or otherwise just simply NOT flat-out wrong) to say about game programming. People hear the word "game", associate it with "insignificant" and promptly shut their brains off. (Much like how average Joes hear the word "computer", associate it with "difficult", and promptly shut their brains off.)

On Monday, 27 May 2019 at 00:33:45 UTC, Nick Sabalausky (Abscissa) wrote:
> flat-out wrong) to say about game programming. People hear the word "game", associate it with "insignificant" and promptly shut their brains off.

Not insignificant, but also not necessarily relevant for the project in this thread.

There is nothing wrong with Robert's approach from a software engineering and informatics perspective.

Why do you guys insist on him doing it your way?

Anyway, if you were to pick up a starting point for a generic GUI engine then you would be better off with Skia than with Unity, that is pretty certain. And it is not an argument that is difficult to make.

On Sun, May 26, 2019 at 6:35 PM Ola Fosheim Grøstad via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Monday, 27 May 2019 at 00:33:45 UTC, Nick Sabalausky
> (Abscissa) wrote:
> > flat-out wrong) to say about game programming. People hear the word "game", associate it with "insignificant" and promptly shut their brains off.
>
> Not insignificant, but also not necessarily relevant for the project in this thread.
>
> There is nothing wrong with Robert's approach from a software engineering and informatics perspective.
>
> Why do you guys insist on him doing it your way?

I don't insist, I was just inviting him to the chat channel where a similar effort is already ongoing, and where there are perf experts who can help.

> Anyway, if you were to pick up a starting point for a generic GUI engine then you would be better off with Skia than with Unity, that is pretty certain. And it is not an argument that is difficult to make.

Unity is perhaps the worst possible comparison point. That's not an
example of "designing computer software like a game engine", it's more
an example of "designing a game engine like a GUI application", which
is completely backwards. Optimising Unity games is difficult and
tiresome, and doesn't really have much relation to high-end games.
There's virtually no high-end games written in Unity, it's made for
small hobby or indy stuff. They favour accessibility over efficiency
at virtually all costs.
They do have the new HPC# ECS framework bolted on the side though,
that's the start of something sensible in Unity.

On Monday, 27 May 2019 at 01:52:05 UTC, Manu wrote:
> I don't insist, I was just inviting him to the chat channel where a similar effort is already ongoing, and where there are perf experts who can help.

Yes, sure, is always a good thing to hash out ideas with others who have an interest in the same field.  Not to change your own ideas, but to see more options. Absolutely!

> Unity is perhaps the worst possible comparison point. That's not an
> example of "designing computer software like a game engine", it's more
> an example of "designing a game engine like a GUI application", which
> is completely backwards. Optimising Unity games is difficult and
> tiresome, and doesn't really have much relation to high-end games.

It does look a bit bloated, but I haven't tried it. Just skimmed over the docs.

Anyway, I think the fact that people buy JUCE is a sure sign that you don't have to provide a perfect UI-framework. You just have to provide a "complete" solution that is better than the alternatives for some specific domains.

For JUCE that appears to be VST audio plugins, so JUCE also provide some DSP algorithms.

Unity and Godot are "complete" solutions for small indy games.

I guess one major decision is to decide whether one provides a limited library or a solution for a domain. Seems to me that it is easier to gain traction by providing a solution.

On 5/26/19 9:32 PM, Ola Fosheim Grøstad wrote:> > Why do you guys insist on him doing it your way?
I never said that. And just to further clarify, I also never said he should USE a game engine for this.

I was only responding to the deluge of misinformation about game-engine-like approaches, all stemming from Manu's suggestion that Robert could get this going an order of magnitude faster without too terribly much trouble. Luckily, Ethan explained my stance better than I was able to.