[Webkit-unassigned] [Bug 71385] Threaded compositor should delegate overflow div/iframe scroll events to WebKit

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=71385





--- Comment #15 from Vangelis Kokkevis <vangelis at chromium.org>  2011-12-01 23:22:06 PST ---
(In reply to comment #14)
> (In reply to comment #13)
> 
> > Simon: This issue seems to keep coming up a lot lately.  The background here (in case it wasn't clear) is that we're working on getting compositing to happen on a thread separate from where the rest of the webkit logic runs. We want to allow that thread to handle basic user input events (mostly scroll for now) on its own whenever possible to improve responsiveness.  In order to effectively do that, we need the composited layer tree nodes to carry more information than they currently do.  Specifically we've had the need for:
> > 1. Tagging fixed position layers so that the compositor can position them while scrolling
> > 2. Tagging overflow layers as scrollable 
> > 3. Tagging scroll areas within a layer in order to avoid scrolling the whole page when we should be scrolling an element (this patch)
> > 
> > With enough contortions we could call out from RLC and RLB to the ChromeClient and set those properties directly to the Chromium layers but it feels that these properties could be generally useful for other ports and should be stored directly into the GraphicsLayer's .  Thoughts?
> 
> The GraphicsLayers tree is an output-only construct, and I think jury-rigging it to contain additional meta-information about the compositing tree may not be the best approach.
> 
> What we really need is:
> * a data structure that describes the transformations that can happen to the compositing tree via scrolling, that is accessible from another thread/process
> * a way to update the (platform-specific) compositing tree on scrolling, from another thread/process
> * a way to notify WebCore that scrolling happened, so it can sync up with the new scroll positions
> 
> I'm concerned about trying to use the GraphicsLayer tree for event handling, also. The bounds of GraphicsLayers often do not correspond with the bounds of the element, so simply using the bounds of some GraphicsLayer to determine you should treat an event as a scroll will often be wrong. You really have to hit-test through WebCore to get the correct answer, or be willing to push a lot of information into another data structure.

What we're after is simply expanding the set of properties stored on the GraphicsLayers to include those necessary for handling scrolling and basic layer layout on the PlatformLayer tree. The flow of information will remain fundamentally one way: From the RenderLayers to the PlatformLayers via the GraphicsLayer tree.  The WebKit thread will always hold the ground truth for all the properties and the GraphicsLayer tree will remain an output only construct.

The model is very similar to what already exists today for transform/opacity animations that are handled by the compositor.  The compositor may be computing new transform and opacity values over time but it doesn't (AFAIK) feed them back to the main tree.  The only updates that we see computed on the compositor are additional scroll offsets that need to be reconciled with WebKit's scrolls but they won't be feeding back through the GraphicsLayer tree.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.