Bug 196508 – Async overflow scroll on iOS paints slowly if it has a negative z-index child

• Component: Scrolling
• Status: ASSIGNED

[Simon Fraser (smfr)]

Created attachment 366531 [details]
Testcase

We seem to get the clipping wrong when painting if we have a negative z-index child.

[Radar WebKit Bug Importer]

<rdar://problem/49532709>

[Simon Fraser (smfr)]

We seem to be using the main-thread-computed clip rects when painting, and should not.

[Simon Fraser (smfr)]

We're clipping the foreground layer to the visible area which is wrong.

[Simon Fraser (smfr)]

And we're triggering repaints on every scroll when setting offsetFromRendering, and resizing the layer.

[Simon Fraser (smfr)]

Fixing flashiness in bug 198458.

[Simon Fraser (smfr)]

Created attachment 371119 [details]
Patch

[Dean Jackson]

Comment on attachment 371119 [details]
Patch

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

> Source/WebCore/ChangeLog:13
> +        Fix by updating the fore- and background-layers last (nothing elese has dependencies

typo: else

> Source/WebCore/rendering/RenderLayerBacking.cpp:1274
> +        if (m_scrolledContentsLayer) {
> +            foregroundSize = m_scrolledContentsLayer->size();
> +            foregroundOffset = m_scrolledContentsLayer->offsetFromRenderer() - toLayoutSize(m_scrolledContentsLayer->scrollOffset());
> +            needsDisplayOnOffsetChange = GraphicsLayer::DontSetNeedsDisplay;
> +        } else {
> +            foregroundSize = primaryGraphicsLayerRect.size();
> +            foregroundOffset = m_graphicsLayer->offsetFromRenderer();
> +        }
> +
> +        if (hasClippingLayer()) {
> +            // If we have a clipping layer (which clips descendants), then the foreground layer is a child of it,
> +            // so that it gets correctly sorted with children. In that case, position relative to the clipping layer.
> +            foregroundSize = FloatSize(clippingBox.size());
> +            foregroundOffset = toFloatSize(clippingBox.location());
> +        }

This can be

if (hasClippingLayer()) {


} else {
 if (m_scrolledContentsLayer) {

 } else {

 }
}

Although I guess you still need the needsDisplayOnOffsetChange... :(

[Simon Fraser (smfr)]

Created attachment 371129 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 371129 [details]
Patch

Clearing flags on attachment: 371129

Committed r246018: <https://trac.webkit.org/changeset/246018>

[Truitt Savell]

The new test compositing/repaint/scroller-with-foreground-layer-repaints.html

added in https://trac.webkit.org/changeset/246018/webkit

is flakey:

History:
http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=compositing%2Frepaint%2Fscroller-with-foreground-layer-repaints.html

Diff:
--- /Volumes/Data/slave/mojave-release-tests-wk1/build/layout-test-results/compositing/repaint/scroller-with-foreground-layer-repaints-expected.txt
+++ /Volumes/Data/slave/mojave-release-tests-wk1/build/layout-test-results/compositing/repaint/scroller-with-foreground-layer-repaints-actual.txt
@@ -33,9 +33,6 @@
                   (offsetFromRenderer width=1 height=1)
                   (bounds 305.00 305.00)
                   (drawsContent 1)
-                  (repaint rects
-                    (rect 0.00 0.00 305.00 305.00)
-                  )
                 )
               )
             )

[Simon Fraser (smfr)]

This is the standard WK1 flakiness. Please mark the test as flakey or skipped.

[Truitt Savell]

Marked test as flakey in:
https://trac.webkit.org/changeset/246334/webkit