Comment by Guzba | Hacker News Reader

Comment by Guzba | Hacker News Reader

Parent Full thread

SVG paths can be arbitrarily complex. This article really doesn't discuss any of the actual hard cases. For example, imagine the character S rotated 1 degree and added to the path on top of itself in a full rotation. This is one path composed of 360 shapes. These begin and end fill sections (winding order changes) coincide in the same pixels at arbitrary angles (and the order of the hits is not automatically sorted!) but the final color cannot be arrived at correctly if you do not process all of the shapes at the same time. If you do them one at a time, you'll blend tiny (perhaps rounded to zero) bits of color and end up with a mess that looks nothing like what it should. These are often called conflation artifacts IIRC.

There's way more to this than drawing circles and rectangles, and these hard cases are why much of path / vector graphics filling still ends up being better on CPU where you can accumulate, sort, etc which takes a lot of the work away. CPU does basically per-Y whereas this is GPU per-pixel so perhaps they're almost equal if the GPU has the square of a CPU power. Obv this isn't quite right but gives you an idea.

Video discussing path filling on CPU (super sampling and trapezoid): https://youtu.be/Did21OYIrGI?t=318 We don't talk about the complex cases but this at least may help explain the simple stuff on CPU for those curious.

Is is it practical to ignore / approximate / offload the complex edge cases?

I want to say yes, but it depends on what you're actually doing as a final goal.

Detecting when a path is antagonistic to most GPU approaches takes time, as does preparing the data however it needs to be prepared on the CPU before being uploaded to the GPU. If you can just fill the whole thing on CPU in that time, you wasted your time even thinking about the GPU.

If you can identify a simple case quickly, it's probably totally a good idea to get the path done on the GPU unless you need to bring the pixels back to the CPU, maybe for writing to disk. The upload and then download can be way slower than just, again, filling on CPU.

If you're filling on GPU and then using on GPU (maybe as a web renderer or something), GPU is probably a big win. Except, this may not actually matter. If there is no need to re-render the path after the first time, it would be dumb to keep re-rendering on the GPU each frame / screen paint. Instead you'd want to put it into a texture. Well.... if you're only rendering once and putting into a texture, this whole conversation is maybe pointless? Then what is simple is probably the best idea. Anyway lots to 2d graphics that goes underappreciated!

No, mostly it is not practical to offload the edge cases.

The reason for this is that the single 2D application that people most want to speed up is font rendering. And font rendering is also the place where the edge cases are really common.

Rendering everything else (geometric shapes) is trivial by comparison.

Why is that? Glyphs can be cached in a texture. That's what nanovg does and it works quite well. That's what my little library does too (https://github.com/audulus/vger)

Doesn't work in the face of real-time dynamic transforms; 3-d, smooth zoom, etc. Atlases are also a bit heavy, so now you need a cache replacement policy, and you have annoying worst-case performance...

Only if you give up doing any script-based languages even remotely properly. And, it really doesn't even work in character-based languages with heavy kerning.

Text rendering is really complicated. There is a reason why we have so few text shaping engines.

Reply on news.ycombinator.com