Open
Bug 1503237
Opened 6 years ago
Updated 2 years ago
Consider moving the InitializeRootDisplayport call from ChromeProcessController to nsLayoutUtils::PaintFrame
Categories
(Core :: Panning and Zooming, enhancement, P3)
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox65 | --- | affected |
People
(Reporter: kats, Unassigned)
References
Details
(Keywords: perf, Whiteboard: [gfx-noted])
Spinoff from Botond's review comment on https://phabricator.services.mozilla.com/D9829
The quick summary is that sometimes we create a top-level window with an HTML document (e.g. the gfx sanity window, maybe addon panels?) and paint it before the task posted from ChromeProcessController [1] has a chance to run. This results in the document not having a displayport, and getting counted as checkerboarded by APZ. This causes spikes in the checkerboarding telemetry data and are undesirable.
Bug 1501046 added a codepath in nsLayoutUtils::PaintFrame so that if we go to paint such a window and it doesn't have a displayport on it yet, it adds one. Botond's suggestion was to always do it this way and get rid of the posted task in ChromeProcessController. This seems worth considering although I'm not sure if this will have unexpected side-effects.
[1] https://searchfox.org/mozilla-central/rev/8848b9741fc4ee4e9bc3ae83ea0fc048da39979f/gfx/layers/apz/util/ChromeProcessController.cpp#44
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•