Bug 64991 - [chromium] Force slow scrolling path for non-composited frames in a composited page
Summary: [chromium] Force slow scrolling path for non-composited frames in a composite...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: James Robinson
URL:
Keywords:
: 64915 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-21 16:21 PDT by James Robinson
Modified: 2011-07-22 12:26 PDT (History)
3 users (show)

See Also:


Attachments
Patch (2.08 KB, patch)
2011-07-21 16:45 PDT, James Robinson
no flags Details | Formatted Diff | Diff
more accurate changelog (1.71 KB, patch)
2011-07-21 17:05 PDT, James Robinson
fishd: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Robinson 2011-07-21 16:21:40 PDT
[chromium] Force slow scrolling path for non-composited frames in a composited page
Comment 1 James Robinson 2011-07-21 16:45:46 PDT
Created attachment 101666 [details]
Patch
Comment 2 Adrienne Walker 2011-07-21 16:49:57 PDT
*** Bug 64915 has been marked as a duplicate of this bug. ***
Comment 3 Adrienne Walker 2011-07-21 17:05:21 PDT
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.
Comment 4 James Robinson 2011-07-21 17:05:50 PDT
Created attachment 101670 [details]
more accurate changelog
Comment 5 James Robinson 2011-07-22 12:26:49 PDT
Committed r91591: <http://trac.webkit.org/changeset/91591>