[Webkit-unassigned] [Bug 78546] Scrolling composited layer fully repainted whenever scroll offset changes

[bugzilla-daemon at webkit.org]

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


Adrienne Walker <enne at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[chromium] Scrolling        |Scrolling composited layer
                   |composited layer fully      |fully repainted whenever
                   |repainted whenever scroll   |scroll offset changes
                   |offset changes              |
                 CC|                            |jchaffraix at webkit.org,
                   |                            |simon.fraser at apple.com




--- Comment #1 from Adrienne Walker <enne at google.com>  2012-02-15 14:13:30 PST ---
The full repaint on scrolling a RenderLayer is coming from here: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderLayer.cpp?rev=107731#L1510

If the layer has its own backing, then scrolling it shouldn't require any invalidations.  I suspect we could use a check similar to FrameView::contentsInCompositedLayer() before doing a full repaint on a scrolled RenderLayer.

Unfortunately, some local testing of that approach reveals another bug in a variation on that testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1344

If you scroll the red box up off the screen and then back on, when the box appears (and becomes composited again), it invalidates the layer below, and will make the text at the top disappear.  Mouse wheel events with discrete scroll jumps repros this better than dragging the scrollbar.

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