Open Bug 1772249 Opened 6 months ago Updated 1 month ago

Jank and checkerboarding when scrolling https://www.waterfox.net/

Categories

(Core :: Graphics: WebRender, defect)

Firefox 103
x86_64
Linux
defect

Tracking

()

Performance Impact ?
Tracking Status
firefox103 --- affected

People

(Reporter: gregp, Unassigned, NeedInfo)

References

(Blocks 2 open bugs, )

Details

Attachments

(7 files, 1 obsolete file)

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

Performance Impact: --- → ?

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(gwatson)
Severity: -- → S3
Flags: needinfo?(gwatson)
Attached file wf4.html

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?

Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(jmuizelaar)
Attached file basic_player.html (obsolete) —
Attached file rocket.lottie.json
Blocks: blob-perf

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.

Flags: needinfo?(nical.bugzilla)
Depends on: 1787706
Attached file enhanced_player.html
Attachment #9291955 - Attachment is obsolete: true

(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?

Blocks: lottie
You need to log in before you can comment on or make changes to this bug.