Bug 143637 – Too much repainting on scrolling with fixed backgrounds

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Simon Fraser (smfr)]

Too much repainting on scrolling with fixed backgrounds

[Simon Fraser (smfr)]

Created attachment 250586 [details]
Patch

[Simon Fraser (smfr)]

rdar://problem/20245243

[Build Bot]

Comment on attachment 250586 [details]
Patch

Attachment 250586 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/5647105804730368

New failing tests:
compositing/repaint/fixed-background-scroll.html

[Build Bot]

Created attachment 250589 [details]
Archive of layout-test-results from ews106 for mac-mavericks-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews106  Port: mac-mavericks-wk2  Platform: Mac OS X 10.9.5

[Darin Adler]

Comment on attachment 250586 [details]
Patch

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

Looks like compositing/repaint/fixed-background-scroll.html failed on the WK2 bot. Clearly that needs to be diagnosed and fixed before landing.

> Source/WebCore/page/FrameView.cpp:1874
> +    if (!usesCompositedScrolling()) {
> +        if (RenderWidget* frameRenderer = frame().ownerRenderer()) {
> +            if (isEnclosedInCompositingLayer()) {

Is this the optimal order for checking these, with the inexpensive checks most likely to fail first?

> Source/WebCore/page/FrameView.cpp:1876
> +                LayoutRect rect(frameRenderer->borderLeft() + frameRenderer->paddingLeft(), frameRenderer->borderTop() + frameRenderer->paddingTop(),
> +                    visibleWidth(), visibleHeight());

Makes me wish this code used points and sizes instead of scalars; the X and Y parts of this computation are the same.

[Simon Fraser (smfr)]

https://trac.webkit.org/changeset/182669