[Webkit-unassigned] [Bug 66969] Chromium: Add a layer for rubber-band overhang painting to the hardware path.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Sep 9 10:25:02 PDT 2011


--- Comment #34 from Adrienne Walker <enne at google.com>  2011-09-09 10:25:01 PST ---
I haven't forgotten you.  Just trying to figure out what to suggest.

(In reply to comment #27)
> Created an attachment (id=106736)
 --> (https://bugs.webkit.org/attachment.cgi?id=106736&action=review) [details]
> Trace requested in comment 26.
> Trace of scrolling normally to the bottom of http://www.webkit.org/blog/386/3d-transforms/, then doing rubber-band scrolling a few times to trigger the overhang drawing.
> Note: That page uses 3D CSS (necessary to trigger this path).

Thanks! From that trace, it looks like at a resolution around 1900x1200, paint and upload combined take a whopping 5ms per 16ms frame when drawing the overhang.  As I feared, it's doing an entire viewport's worth of painting and texture uploads when you have both overhangs.  I'm not comfortable with that.

Part of the problem is the naive way that invalidations are being unioned together in TiledLayerChromium (so L-shapes become squares), and this should be fixed in a separate patch.  It's on my radar as bug 67854, but I've been busy.

I'll mention that there's some design discomfort here with how this is being done, that's likely causing some reluctance to review this patch.  For some background, we're working towards having Chromium's compositor be able to scroll in a separate thread without needing WebKit paints, so having to repaint every scroll defeats that purpose, even if it's just in this edge case.  So, although I agree with you that it's nice to be correct first and fast second, it's hard not to look at this patch as introducing technical debt that somebody from the GPU team will have to pay in the future.

In an ideal world, I'd want these gradient borders and repeating texture backgrounds as a feature on LayerRendererChromium, which could draw and upload both more efficiently and more generally.  That seems like the right place to put this logic. Unfortunately, that approach is a good bit more complex than this patch.

I think what you have is probably the simplest correct solution, even if I'm not that happy with the #ifdef warts.  However, the performance makes me really uncomfortable.  I'm also not a reviewer, so you may want to work on convincing somebody else who is.

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

More information about the webkit-unassigned mailing list