Bug 65056 - Enable fast path scrolling for composited iframes
Summary: Enable fast path scrolling for composited iframes
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: Adrienne Walker
URL:
Keywords:
: 61806 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-22 16:17 PDT by Adrienne Walker
Modified: 2011-08-11 13:43 PDT (History)
8 users (show)

See Also:


Attachments
Patch (6.88 KB, patch)
2011-07-22 16:24 PDT, Adrienne Walker
no flags Details | Formatted Diff | Diff
Patch (17.83 KB, patch)
2011-08-01 16:55 PDT, Adrienne Walker
no flags Details | Formatted Diff | Diff
Patch (17.65 KB, patch)
2011-08-02 09:52 PDT, Adrienne Walker
jamesr: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrienne Walker 2011-07-22 16:17:26 PDT
Enable fast path scrolling for composited iframes
Comment 1 Adrienne Walker 2011-07-22 16:24:52 PDT
Created attachment 101789 [details]
Patch
Comment 2 James Robinson 2011-07-22 16:36:03 PDT
Comment on attachment 101789 [details]
Patch

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

I'd like to see a test for the following testcase to see if it's OK to disregard the overlap test:

<iframe id="a" class="composited"></iframe>
<iframe id="b" class="noncomposited"></iframe>

where b overlaps a

i'm not 100% sure if b will be put into a composited layer in this case.  If it always will, then I agree it's fine to ignore the overlap test when considering whether to fast scroll inside a's FrameView.

> Source/WebCore/page/FrameView.cpp:1150
> +    if (contentsInCompositedLayer())

is it OK to ignore m_useSlowRepaints for composited layers?
Comment 3 Collabora GTK+ EWS bot 2011-07-22 17:35:51 PDT
Comment on attachment 101789 [details]
Patch

Attachment 101789 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/9226327
Comment 4 Adrienne Walker 2011-07-22 18:04:45 PDT
(In reply to comment #2)
> (From update of attachment 101789 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=101789&action=review
>
> > Source/WebCore/page/FrameView.cpp:1150
> > +    if (contentsInCompositedLayer())
> 
> is it OK to ignore m_useSlowRepaints for composited layers?

setUseSlowRepaints() is called in three places, all in RenderView.  All of which appear to be related to layers that have reflections, transforms, or transparency.  If you were doing this in software, I could see how these might cause blitting problems when scrolling.  However, if the layer has its own backing, none of these should be an issue.

I was tempted to rename this to setCannotBlitToWindow() to make this more clear.  I can also add more tests for all these cases.  :)
Comment 5 Adrienne Walker 2011-08-01 16:55:47 PDT
Created attachment 102591 [details]
Patch
Comment 6 Gustavo Noronha (kov) 2011-08-02 07:37:30 PDT
Comment on attachment 102591 [details]
Patch

Attachment 102591 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/9284720
Comment 7 Adrienne Walker 2011-08-02 09:06:33 PDT
Comment on attachment 102591 [details]
Patch

Taking off review until I can address that gtk issue.
Comment 8 Adrienne Walker 2011-08-02 09:52:14 PDT
Created attachment 102661 [details]
Patch
Comment 9 Adrienne Walker 2011-08-02 09:53:26 PDT
(In reply to comment #8)
> Created an attachment (id=102661) [details]
> Patch

Whoops, forgot the #if guard for accelerated compositing.  Thanks, ews bot!
Comment 10 Adrienne Walker 2011-08-03 16:37:55 PDT
*** Bug 61806 has been marked as a duplicate of this bug. ***
Comment 11 James Robinson 2011-08-10 12:29:26 PDT
Comment on attachment 102661 [details]
Patch

R=me
Comment 12 Adrienne Walker 2011-08-11 13:43:29 PDT
Committed r92874: <http://trac.webkit.org/changeset/92874>