Steps to reproduce:

1. Navigate to https://www.waterfox.net/
2. Scroll the page

Actual results:
Jank and checkerboarding

Expected results:
Less jank and checkerboarding

https://share.firefox.dev/3x30fjl

The severity field is not set for this bug.
:gw, could you have a look please?

For more information, please visit auto_nag documentation.

Extracted SVG blob image

With the attached HTML file that draws an SVG as a blob, this seems much slower to draw in Gecko than it does in Chromium.

It's quite possible that I'm incorrectly measuring something, there's a heap of variables in play, but:

• I set gfx.webrender.blob-tile-size to 2048 (just for simplicity of timing).
• I disabled GPU raster in chromium.

On my machine, the recorded time inside rasterize_blob is typically 8 - 10ms. If I look at the performance profiler in chromium, there are 4 raster threads. It's hard to know which ones account for the SVG image, as there are many raster jobs, but all together they seem less than the 8-10ms we see in rasterize_blob. There is one large raster job in chromium that takes 1.5 ms, and a heap of smaller ones.

Although it's quite a complex SVG, that time seems much higher than I would expect to raster an image of size 1000 x 500, I think? What do you think jrmuizel / nical?

We spend a lot of time allocating memory in this test case (and we have noticed that in a lot of other test cases).
It's not obvious to me whether we can easily do something about it, but if skia makes any effort to reuse allocations we probably nullify it by re-creating the SkSurface for every tile.

Bumping the tile size to 512 improves things a lot (almost halves the rasterization time and also improves the upload times), I've been meaning to do that for a long while.

rocket.lottie.json: https://share.firefox.dev/3Q1vUct
no_telemetry.lottie.json: https://share.firefox.dev/3pTUlhj
private_browsing.lottie.json: https://share.firefox.dev/3QYlA6v
ml_powered_translations.lottie.json: https://share.firefox.dev/3CGDI0k
tracking_protection.lottie.json: https://share.firefox.dev/3RlHCj6

(In reply to Nicolas Silva [:nical] from comment #10)

We spend a lot of time allocating memory in this test case (and we have noticed that in a lot of other test cases).
It's not obvious to me whether we can easily do something about it, but if skia makes any effort to reuse allocations we probably nullify it by re-creating the SkSurface for every tile.

Bumping the tile size to 512 improves things a lot (almost halves the rasterization time and also improves the upload times), I've been meaning to do that for a long while.

That doesn't seem to match what I see in this test case on my machine. Bumping the blob size to 512 results in the same (or worse) overall raster time in the attached test case:

rasterize_blob Rect(238x512 at (512, 0)) t=3.27763 ms
rasterize_blob Rect(512x512 at (0, 0)) t=4.626926 ms

It is a relatively complex SVG but that amount of time to rasterize it at 750 x 512 seems really high, to me (on a ThreadRipper PRO 3975WX)? I don't have any real evidence to support it, but I can't help but wonder if there's something else going on rather than just some extra memory allocation that makes us much slower in this case that chromium seems to be?

The severity field for this bug is set to S3. However, the Performance Impact field flags this bug as having a high impact on the performance.
:gw, could you consider increasing the severity of this performance-impacting bug? Alternatively, if you think the performance impact is lower than previously assessed, could you request a re-triage from the performance team by setting the Performance Impact flag to ??

For more information, please visit auto_nag documentation.