Long pinch actions seem to continuously increase CPU (compositor) time
Categories
(Core :: Graphics: WebRender, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox69 | --- | fixed |
People
(Reporter: kats, Assigned: jnicol)
References
(Blocks 1 open bug)
Details
(Whiteboard: [gfx-noted][wr-amvp][wr-q2][wr-april])
Attachments
(1 file, 1 obsolete file)
(deleted),
text/x-phabricator-request
|
Details |
On Android, if you zoom in and out slightly for a long time with the webrender profiler HUD on, the CPU (compositor) graph shows the time increasing per frame as long as you continue the pinching action. Seems kind of odd, like we're accumulating some state or not freeing stuff until the user lets go of the pinch.
Reporter | ||
Comment 1•6 years ago
|
||
http://bit.ly/2SvxGoD is an unsymbolicated profile. Not super useful but it shows the memory increasing throughout which is probably related.
Comment 2•6 years ago
|
||
These profiles doen't seem to have Renderer thread. Also, do you know why they're unsymbolicated?
Reporter | ||
Comment 3•6 years ago
|
||
I forgot to add the Renderer thread. I knew I was forgetting one :) As for symbolication, not sure exactly but it was a local build with a mozconfig I had lying around so maybe didn't have the right options.
Comment hidden (typo) |
Updated•6 years ago
|
Updated•6 years ago
|
Reporter | ||
Comment 5•6 years ago
|
||
https://perfht.ml/2SLH4EM is more symbolicated and has the Renderer thread. Clearly shows increasing composite times.
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Comment 6•6 years ago
|
||
Now with Bobby's patches from bug 1532810: https://perfht.ml/2XHg5h9
copy_image_sub_data seems to be the winner
Reporter | ||
Comment 7•6 years ago
|
||
At least some of the problem seems to be the default eviction algorithm. We might need to tune it more for Android. Reducing the MAX_MEMORY_PRESSURE_BYTES seemed to improve the performance a bit.
Reporter | ||
Updated•6 years ago
|
Assignee | ||
Comment 8•6 years ago
|
||
The problem seems to be that pinch zooming fills up the texture cache incredibly quickly. I assume because we cache glyphs/images for every slight change in zoom level, compared to on desktop when we zoom at discrete increments.
So it grows very large, and whenever it is resized we need to perform a copy of the entire thing.
FWIW I also see this on my OnePlus 6, though not nearly as serverely.
Tweaking with the eviction algorithm definitely seems like it would help. We could also resize the cache in larger increments so that we don't have to copy as frequently. Also if we can delay resizing until we know exactly how large the cache needs to be that would mean worst case one copy per frame, but I don't know how feasible that is.
Comment 10•6 years ago
|
||
We should also probably not be trying to cache glyphs for every slight change in zoom level.
Assignee | ||
Comment 11•6 years ago
|
||
Yeah I think that would help significantly.
Just for a sense of scale, a few zooms in and out of planet.mozilla.org grows my texture cache to >200 layers
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 12•6 years ago
|
||
Yeah, it seems like the issue here is less about our eviction algorithms being miscalibrated for android and more that we need to handle continuous scaling downstream of the texture cache.
Comment 13•6 years ago
|
||
Also, we should make sure we're not kicking off lots of CPU glyph rasterization tasks for all the different zoom levels.
Assignee | ||
Comment 14•6 years ago
|
||
I have a WIP patch doing just that. It seems like the eviction policy might also need tweaked, but it's a huge improvement.
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 15•5 years ago
|
||
When pinch zooming webrender would re-rasterize glyphs for each tiny
difference in zoom level. This takes time in itself, but also causes
the texture cache to grow incredibly large, to the point where
resizing it to make room for more glyphs takes far too much time.
This patch avoids this by rounding the size at which glyphs are
rasterized whilst pinch zooming. To do this we add a FrameMsg which
APZ uses to tell webrender whether a spatial node is being pinch
zoomed. Then during frame building if a spatial node is being pinch
zoomed we override the raster space of its corresponding picture.
The chosen raster space is the current zoom level rounded up to the
nearest power of two, but not exceeding 8x. This seems to be a good
balance between quality and performance, though at high zoom levels
the cache still does grow very large due to the size of the glyphs.
Comment 16•5 years ago
|
||
Pushed by jnicol@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/582dab79ef68 Avoid excessive glyph rasterization when pinch zooming. r=gw,kats
Comment 17•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•5 years ago
|
Description
•