After doing some archeology (see r16129), the code is used to avoid FOUCs by preventing paints to propagate to child RenderLayers (meaning that there will be a flash to white instead). It was later extended to allow for paints suppression. All the conditions that the function checks are tied to the document - the exception being that it checks for child layer - which means that instead of having a fixed cost per paint phase, it's a cost per RenderLayer::paintLayer. On http://dglazkov.github.com/performance-tests/biggrid.html, this is an ~8 - 10% cost as we need to do a lot of paintLayer calls. At the time the function was introduced, it's unclear if the painting went through a single point as it does now but we can easily move the code to the FrameView now. Patch forthcoming.
Created attachment 145917 [details] Proposed change v1.
Comment on attachment 145917 [details] Proposed change v1. What happens when there are compositing layers, which can enter painting on a non-root RenderLayer? Or do we never have compositing layers this early on?
Comment on attachment 145917 [details] Proposed change v1. r- until we resolve the compositing issue.
(In reply to comment #2) > (From update of attachment 145917 [details]) > What happens when there are compositing layers, which can enter painting on a non-root RenderLayer? Or do we never have compositing layers this early on? The compositing code is bypassing the checks for the owning layer already as RenderLayerBacking::paintContents calls directly RenderLayer::paintLayerContents. However you would not paint the descendant layers as you would need to go through RenderLayer::paintLayer. I don't think anything prevents us from having compositing layers during a potential FOUC so the logic needs to be changed.
Mhh, it also looks like the new logic wouldn't repaint the RenderView or the document's element which means we wouldn't paint the background and do a "flash to white" like the old code. It doesn't sound like a good idea to change that.