Re: Why is SVG rendering so slow?

On 7/18/17 11:07 PM, /#!/JoePea wrote:
> Hello Daniel,
> 
> That was my mistake, I meant for Two.js to use its WebGLRenderer. Here
> are the updated demos:
> 
> - https://jsbin.com/gukutebava/1/edit?js,output (Two.js)
> - https://jsbin.com/cocuhivomu/edit?js,output (Pixi.js)
> - https://jsbin.com/puzetodira/edit?js,output (SVG, using transform)

Looks like the SVG version here is still using "cx" / "cy".

Though if I change it to use transform, it looks like (on my machine at
least) we run up against some limit and fail to allocate new graphics
textures until I close that tab -- I see chunks of the page disappearing
and logging to my terminal like the following:
  [GFX1-]: Failed 2 buffer db=0 dw=0 for 0, 0, 240, 240

I don't know what exactly is happening under the hood in the
(canvas-based) Two.js / Pixi.js examples -- and FWIW, they're a bit
janky on my system too, though not quite as janky.

Anyway -- I don't have a solid answer for you about the difference,
except for the following (based on some quick performance profiles that
I made [and you can too!] using the gecko profiler extension from
https://perf-html.io):
 - In your SVG demo without 'transform', we spent all of our time
repainting after each move.
 - With 'transform', we seem to run up against some limit of layers (on
my machine at least), as noted above, and fall over.
 - I presume the faster canvas-backed examples are using some
lighter-weight shim above the hardware to avoid these problems, since
they don't spend anywhere near as much time in rasterization -- though
I'm not sure about the details.

Basically, our SVG implementation is not designed with this "thousands
of things moving around at once" use-case as a primary target. It's
pretty good at rendering static content, and it's good at rendering some
limited amount of moving content at once -- and even better if that
stuff is moving with "transform", which lets us allocate a dedicated
layer for the moving thing.  (But that only works up to a certain
point.)  If your sort of example were a common use-case, it's likely we
would have invested more time in optimizing for it. :) But as it stands,
SVG doesn't get a ton of developer resources right now.

It's possible that the performance will be better with WebRender,
though! (WebRender is a next-generation GPU-based painting engine on the
tip of the rendering pipeline, used in our research browser engine Servo
& which might make it into Firefox): https://github.com/servo/webrender

I think WebRender's SVG capabilities are somewhat limited at the moment,
though this might get a lot better once those are fully baked.

~Daniel