[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 #13 from Vangelis Kokkevis <vangelis at chromium.org>  2011-11-30 10:24:27 PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > (From update of attachment 116256 [details] [details] [details])
> > > View in context: https://bugs.webkit.org/attachment.cgi?id=116256&action=review
> > > 
> > > > Source/WebCore/platform/graphics/GraphicsLayer.h:307
> > > > +    // Set coordinates of scrollable elements inside the layer. These are given
> > > > +    // in scaled document coordinates.
> > > > +    const Vector<IntRect>& scrollableRects() const { return m_scrollableRects; }
> > > > +    virtual void setScrollableRects(const Vector<IntRect>& r) { m_scrollableRects = r; }
> > > 
> > > It's not clear what "scrollable rects" are for. Why aren't the child scrollable things in their own GraphicsLayers?
> > 
> > Scrollable rectangles inside a layer signify areas where the chromium compositor thread should not attempt to process scroll events by itself (by translating the layer coordinates), but instead it should forward those events to the WebKit thread. These areas are created for things like iframes and elements with overflow scrolling which do not have a RenderLayerBacking of their own.
> 
> This sounds like information that should be kept in the chromium layer, not pushed down to GraphicsLayer.

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?

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