Hacker News Reader

Comment by kllrnohj | Hacker News Reader

It's either just using SVG at all that's the problem or something in the SVG that's a problem. SVGs are generally not GPU rasterized since GPUs are really not built for paths. That's a whole research area in and of itself.

There are things you can attempt depending on your browser, though, such as avoiding non-convex paths in the SVG.

If you want good performance everywhere though the only real option is just don't use SVG if you need to animate it.

View on HN

> SVGs are generally not GPU rasterized since GPUs are really not built for paths. That's a whole research area in and of itself.

It's not so much that GPUs aren't built for paths as that winding rules are not suited for parallelism. The solution is to use meshes instead of paths. This is my current area of work.

Is this the generalization of the Pathfinder text renderer?

Do you mean the non-zero rule and even-odd rules? In the WP definition they don't inherently seem to have side effects or dependencies on previous computations, can you link to an elaboration?

Computing whether a pixel is filled requires computing its winding number, which depends on every path before it on the scanline. This is not a problem for a sequential algorithm, since you compute winding numbers as you go, but it is a problem if you want to fill every pixel in parallel.

> GPUs are really not built for paths

I remember a whole slew of "accelerated 2D" cards in the mid-1990s that had faster Windows GDI performance than we have today for certain 2D operations such as path drawing (the regression was in Windows Vista when they moved all GDI operations to the CPU).

Reply on news.ycombinator.com