1503237 - Consider moving the InitializeRootDisplayport call from ChromeProcessController to nsLayoutUtils::PaintFrame

Status: NEW

(Core :: Panning and Zooming, enhancement, P3)

Description

[Kartikaya Gupta (email:[e-mail])]

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