Bug 64991 – [chromium] Force slow scrolling path for non-composited frames in a composited page

• Component: New Bugs
• Status: RESOLVED FIXED

[James Robinson]

[chromium] Force slow scrolling path for non-composited frames in a composited page

[James Robinson]

Created attachment 101666 [details]
Patch

[Adrienne Walker]

*** Bug 64915 has been marked as a duplicate of this bug. ***

[Adrienne Walker]

Comment on attachment 101666 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=101666&action=review

Unofficially, the code looks good to me.  We could also cut the explanation out and just say we don't handle it.

> Source/WebCore/ChangeLog:10
> +        The chromium compositor does not properly handle fast path scrolls for non-composited iframe in a composited
> +        page. In particular, we don't receive invalidations that are outside the viewport bounds for non-composited
> +        iframes, but we still try to use the contents from tiles that extend outside the viewport when they are scrolled
> +        in to view.  For the main frame we do receive invalidations outside the viewport (see
> +        FrameView::clipsRepaints()) so everything works out.

I thought the larger issue was that we don't handle the different scroll offsets from the main frame and the sub frame.  This causes a problem because we're scrolling via redrawing the root directly at the scroll offset rather than scrolling via copying a rectangle from the backbuffer based on the offset that gets passed to WebViewImpl::scrollRootLayerRect.

[James Robinson]

Created attachment 101670 [details]
more accurate changelog

[James Robinson]

Committed r91591: <http://trac.webkit.org/changeset/91591>