Janky WebRender scrolling on reallifecomics.com with Renderer thread swamped in draw_alpha_batch_container
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
People
(Reporter: bholley, Unassigned)
References
(Blocks 1 open bug)
Details
I noticed this on my pixel 2 last night, and just reproduced on my MBP (External display, discrete Radeon GPU).
STR:
- Visit https://reallifecomics.com/index.php
- Zoom so that the blog text occupies the full width of the viewport
- Scroll up and down rapidly to experience modest jank
The HUD profiler shows high CPU time on the renderer thread. I captured a profile and it looks like this:
https://share.firefox.dev/3gIDpnw
The selected segment comes from finding the janky segments in the marker chart on the compositor thread and the zooming to that. Switching over to the renderer thread for that interval, we see a bunch of time in the GL driver under glBufferData. I don't believe this is a mac driver quirk though, because I saw the same thing on Android (though I haven't profiled it on that device).
Comment 1•4 years ago
|
||
Looks like another glyph bounds batching disaster. I'll make sure to test against this one because the glyphs are spaced very close together, so we'll need to be very accurate with the bounds to avoid breaking batches
Updated•4 years ago
|
Comment 2•4 years ago
|
||
This was certainly helped by bug 1645665, but is still quite bad. Looking closer at the page, I think a lot of the glyphs do in fact overlap, which means that approach cannot fix them.
To improve this further we could increase the size of the texture arrays and/or be more aggressive about eviction, both to reduce the chances of fragmentation. We could also look in to binding multiple textures in the shader. And I believe Glen was also considering caching entire runs of rasterized glyphs together, which would help.
Updated•3 years ago
|
Description
•