[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 #16 from James Robinson <jamesr at chromium.org>  2012-11-19 14:34:05 PST ---
(In reply to comment #15)
> (In reply to comment #10)
> > Patching this at the WebKit layer is wrong, we should fix this in WebCore.  It's not anything specific to chromium or any particular embedding of WebCore - when the page scale changes, all content on the page needs to be invalidated.  
> 
> It is true that when the page scale changes we need to issue a redraw, and we also need to repaint all layers that have contents scale changed. Both are happening correctly. The only exception is NCCH for the reason I explained in previous post.
> 
> It is indeed a chromium problem -- only chromium has this NCCH layer that steals contents from RenderView. If it's the embedder who re-route the painting to a different layer, then it's also the embedder's responsibility to re-route the invalidation.

That's not true.  Every port with compositing has to deal with the non-composited (according to WebCore) content.

> 
> > This isn't a theoretical concern - we expose a window.internals function to set the page scale from layout tests (implemented in WebCore/testing/InternalSettings.cpp) that hooks directly in to WebCore::Page.  This needs to have the same behavior as the actual product or layout tests intended to cover page scale will not actually cover all the logic we ship.
> 
> DumpRenderTree doesn't use NCCH if my memory is correct.

No, it does.

> 
> > Invalidating from WebCore should be quite easy.  NCCH hosts the content that is not considered composited by WebCore (hence the name), so invalidations on the hostWindow are routed to NCCH.  Calling repaint() on root Document's RenderObject should result in a correctly-sized repaint coming out via WebCore::Chrome::invalidateContentsAndRootView().  That's how style changes (such as background color) are repainting, so if that path is not working then I would expect us to see significantly more breakage.
> 
> Background color change will work, because it implies a repaint. In contrast, changing transform matrix on a compositing layer doesn't need a repaint -- the compositor just has to redraw the layer using a different quad.

Right, but changing the page scale should generate a repaint as well.

> 
> (In reply to comment #11)
> > (In reply to comment #8)
> > > 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.
> > 
> > WebCore is responsible for this property, not the compositor.
> 
> I think it's updateLayerContentsScale in layer_tree_host_common.cc
> I don't see why WebCore is responsible for contents scale. With the new scaling model, WebCore should not even know about the existence of the page scale factor.

WebCore is responsible for the page scale factor.

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