Bug 80641 – REGRESSION (r93614): scrolling div does not repaint

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Shawn Singh]

I believe it is a simple fix, but Julien should be able to make the "correct final fix" far more quickly and with awareness of the performance issues involved.

cc Dana just in case this is magically related to our other bugs where paint rects seem wrong, too.

To reproduce the problem:
   go to http://www.railgun3d.com:8080/gltest5/demo.htm   (requires webGL)
   scrolling the div does not repaint the divs contents.

If you cannot reproduce:
   go to inspector
   turn off "position: absolute" for the 200x200 div that has the scrollbar
   turn it back on.
   now it should reliably reproduce.

The problem is that the repaint rect associated with the 200x200 div is not re-computed, and therefore its position is way off to the side.  I bisected this down to 93614.

Hacked solution:
  forcing computeRepaintRects() in all cases for RenderLayer::updateLayerPositionsAfterScroll does indeed fix the problem.

[Shawn Singh]

To save time for Julien, he essentially told me the correct fix (and it seems to work);  I'll create a reduced test case, verify the fix, and upload a patch.

Thanks Julien!

[Simon Fraser (smfr)]

http://trac.webkit.org/changeset/93614

[Shawn Singh]

Update - our expected fix was not yet correct.  Needs further investigation, there seem to be enough clues to continue investigating.

[Shawn Singh]

I've traced through the problem, and I have it figured out.  Patch is coming in a moment.

1. At first, there is a non-composited layer which paints into an ancestor repaintContainer.  because it is positioned, the repaintRect has a non-zero offset.

2. Then, the layer changes position, and becomes composited.  At that time, we are not updating the repaintRect.  (The code in FrameView::layout() calls updateLayerPositions() where repaintRects are already computed, before updateCompositingLayers().)

3. However, because the layer became composited, it became its own repaintContainer, and the repaintRect should have been updated.  But its not, and the repaint rect is skewed by some incorrect offset, and the actual contents don't get repainted.

I feel it is correct to computeRepaintRects when a newly composited layer is created.  Specifically, we have to wait until the backing is created before we can computeRepaintRects correctly.

[Shawn Singh]

Created attachment 131162 [details]
Patch

The included layout test reproduces the problem on both webkit nightly and tip-of-tree chromium before this patch is applied.

[Simon Fraser (smfr)]

Comment on attachment 131162 [details]
Patch

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

> LayoutTests/compositing/repaint/newly-composited-repaint-rect.html:67
> +        if (window.layoutTestController) layoutTestController.display();

Use two lines for this.

[Shawn Singh]

Created attachment 131258 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 131258 [details]
Patch for landing

Clearing flags on attachment: 131258

Committed r110401: <http://trac.webkit.org/changeset/110401>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.