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).

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

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.