[Webkit-unassigned] [Bug 100718] Invalidate non-composited content host when page scale factor changes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=100718





--- Comment #8 from Tien-Ren Chen <trchen at chromium.org>  2012-11-07 21:22:23 PST ---
After carefully examining the whole invalidation process, I think this is the proper fix.

The story goes like this:
1. WebViewImpl::setPageScaleFactor calls Page::setPageScaleFactor, which calls document->recalcStyle(Node::Force) to update the transform.
2. During the style update, RenderObject::setStyle detects the transform change on the RenderView. Since it is only a transform change, repaint is not needed (StyleDifferenceRecompositeLayer).
3. Supposedly if the compositor wants to change the contents scale to repaint a high-res version, it is the compositor's responsibility to invalidate the layer. The compositor actually does it, but on the RenderView layer, which is a no-op since RenderView layer is non-drawing layer because its content is stolen by the non-composited content layer.
4. Nobody tells non-composited content layer to repaint --> tile busted

This phenomenon is not obvious, because some area of the non-composited content layer are still invalidated for other reasons:
1. renderView->setNeedsLayout(true)
   This line doesn't really do any change to the layout. The purpose is only to update some internal variables. Regardless, it cause the RenderView to repaint its rect, which is totally bogus as the document node doesn't represent any contents, and its rect is set to the size of layout viewport only for layout purpose.
   That is why we can see the upper left part of the layer being repainted, and the size is exactly the viewportSize*pageScaleFactor, which is the size of the RenderView after transformation.
2. The enlarged part of the layer automatically gets invalidated.
   When we pinch zoom-in, the region that was not previously inside the layer bound always get the newest contents.

Combine reason 1. and 2., that is why we can't observe the phenomenon when pageScaleFactor >= 1.0 and doing zoom-in, nor when pageScaleFactor >= 1.0 and have scrollOffset == (0, 0).


The conclusion is that neither the compositor or WebCore is doing anything wrong. The correct fix is to notify the non-composited content host that the RenderView transform changed, thus needs a repaint. Currently the only thing that can change RenderView transform is the pageScaleFactor, therefore I think adding a hook in WebViewImpl::setPageScaleFactor is reasonable.

Now the real question is how to test this fix. I don't think DumpRenderTree uses the NonCompositedContentHost hack. We probably need to implement a webkit_unit_tests for that. I would say it is a non-trivial task and we might need to postpone the test until other high priority bugs are fixed.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.