Bug 201019 - Migrate from m_styleRecalcTimer to scheduled rendering updates
Summary: Migrate from m_styleRecalcTimer to scheduled rendering updates
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 202843
  Show dependency treegraph
 
Reported: 2019-08-21 18:43 PDT by Simon Fraser (smfr)
Modified: 2021-03-04 09:38 PST (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2019-08-21 18:43:08 PDT
We should be able to remove the m_styleRecalcTimer and just schedule rendering updates now (via RenderingUpdateScheduler).
Comment 1 Simon Fraser (smfr) 2020-12-22 11:55:22 PST
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.
Comment 2 Simon Fraser (smfr) 2020-12-22 11:57:26 PST
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
Comment 3 Ryosuke Niwa 2020-12-22 12:20:54 PST
(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.
Comment 4 Simon Fraser (smfr) 2020-12-22 13:13:38 PST
But why not make layer tree freezing (bad name) a webcore feature, rather than a webkit feature? All ports could benefit.
Comment 5 Simon Fraser (smfr) 2020-12-22 13:47:13 PST
fast/events/onunload-not-on-body.html is the test that broke
Comment 6 Ryosuke Niwa 2020-12-23 00:23:34 PST
(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.