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

Wed Nov 30 11:21:05 PST 2011

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

--- Comment #14 from Simon Fraser (smfr) <simon.fraser at apple.com>  2011-11-30 11:21:05 PST ---
(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.

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