Bug 201019 – Migrate from m_styleRecalcTimer to scheduled rendering updates

• Status: NEW
• Component: Layout and Rendering

[Simon Fraser (smfr)]

We should be able to remove the m_styleRecalcTimer and just schedule rendering updates now (via RenderingUpdateScheduler).

[Simon Fraser (smfr)]

There's a problem with this. We rely on style updates from this timer to reach the "visually non-empty" state, which is necessary to unfreeze the layer tree.

When the layer tree is frozen, TiledCoreAnimationDrawingArea::triggerRenderingUpdate() bails early so we get stuck.

[Simon Fraser (smfr)]

I think we’d have to move layer tree freezing into webcore, and have Page::updateRendering() do the first layout, but bail early when the tree is frozen

[Ryosuke Niwa]

(In reply to Simon Fraser (smfr) from comment #2)
> I think we’d have to move layer tree freezing into webcore, and have
> Page::updateRendering() do the first layout, but bail early when the tree is
> frozen

I think this is backwards. Instead of moving layer tree freezing into WebCore and letting TiledCoreAnimationDrawingArea::triggerRenderingUpdate invoke updateRendering just to make a progress in the "visually non-empty" state, TiledCoreAnimationDrawingArea::updateRendering should just know this is happening and trigger the initial layout anyway. So add something like Page::updateRenderingForFirstTimeIfNeeded and always call that when the layer tree is frozen.

[Simon Fraser (smfr)]

But why not make layer tree freezing (bad name) a webcore feature, rather than a webkit feature? All ports could benefit.

[Simon Fraser (smfr)]

fast/events/onunload-not-on-body.html is the test that broke

[Ryosuke Niwa]

(In reply to Simon Fraser (smfr) from comment #4)
> But why not make layer tree freezing (bad name) a webcore feature, rather
> than a webkit feature? All ports could benefit.

You mean the logic to avoid painting when there is a page load happening? Don't we also use it for other purposes too? It's unclear to me what we call as layer tree freezing is what we want across all the ports. I suspect there is a subset of things it does like skipping rendering updating steps and/or painting that might be beneficial across ports. If you're talking about extracting it and moving it to WebCore, that does seem reasonable but it would be a lot bigger engineering task then.