[Webkit-unassigned] [Bug 67883] Move root layer creation semantics to the outside of chromium compositor

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 13 18:51:55 PDT 2011


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





--- Comment #9 from James Robinson <jamesr at chromium.org>  2011-09-13 18:51:55 PST ---
(From update of attachment 107260)
View in context: https://bugs.webkit.org/attachment.cgi?id=107260&action=review

This looks really great.  Unfortunately since I had to revert the contents texture manager patch this patch doesn't seem to apply to current ToT.  I have an updated version of that patch up here: https://bugs.webkit.org/show_bug.cgi?id=67440 so hopefully it'll land soon and unblock this one.

Left some comments, not touching review? flag yet until the dependent patch lands.

> Source/WebCore/platform/graphics/chromium/NonCompositedContentHost.cpp:82
> +void NonCompositedContentHost::clearRenderSurfacesRecursive(LayerChromium* layer)

this function feels misplaced - CCLayerTreeHost has a pointer to the root of the LayerChromium tree and should be the only class that has to deal with the implementation details of them

> Source/WebKit/chromium/src/WebViewImpl.cpp:2790
> +        m_nonCompositedContentHost->setVisible(visible);
> +        m_layerTreeHost->setVisible(visible);

this seems like a bit of a code smell - especially since the order of calls here is essential (NonCompositedContentHost::setVisible protects textures and then CCLayerTreeHost::setVisible deletes all unprotected textures beyond a given threshold).

Maybe instead of treating this as an abstract thing (tell the NCCH and LTH about the new visibility) it'd be better to make the nonCompositedContentHost more explicit? something like:

if (!visible)
  m_nonCompositedContentHost->protectVisibleRootTileTextures();
m_layerTreeHost->setVisible(visible)

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



More information about the webkit-unassigned mailing list