1746625 - Bad surface pool behaviour during scrolling on https://health.mo.gov/living/healthcondiseases/communicable/novel-coronavirus/data/public-health/

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

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

We evict a bunch and then create a bunch in the next frame.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Markus, is this behaviour expected?

Comment 2

[Markus Stange [:mstange]]

View into the SurfacePool profiler markers: https://share.firefox.dev/3z1Nwy5

We have all kinds of different surface sizes on this page. I'm not sure why - I thought regular WebRender painting went into 1024x512-sized surfaces. Is it canvases?

The surface pool has a limit of 25 unused surfaces, configurable with gfx.webrender.compositor.surface-pool-size. Anything beyond that is evicted at the end of a frame. For this to work well, we need to have good surface reuse. But good surface reuse is only possible if we have only a small set of surface sizes. What seems to happen in this profile is that we require a different set of surface sizes in each frame.

Furthermore, I'm surprised WR asks us to bind so many surfaces each frame. Example: https://share.firefox.dev/3pyJ3Qh
Each "Create" or "Recycle" event in the surface pool is due to a request from WR to bind a surface. I can see some frames with at least 20 of those, but the corresponding "NumPictureCacheInvalidated" marker only says "4" or "5". I'm not sure what this means.