[Webkit-unassigned] [Bug 70084] [Chromium] Add WebAcceleratedContentLayer backed by a texture to support accelerated content hosting

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Antoine Labour <piman at chromium.org>  2011-10-14 18:00:59 PST ---
(In reply to comment #10)
> (From update of attachment 111099 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=111099&action=review
> 
> I think you should explicitly document how the compositor will use the passed-in texture.  I believe that with our current implementation it would be something like:
> 
> In single threaded mode, the texture will only be used during an invocation of WebLayerTreeView::composite()
> In multi threaded mode, the texture may be used starting at some undetermined time after the texture ID is set (specifically at the first commit) and then used at arbitrary points in time up until an undetermined time after the texture id or layer is destroyed, or until the WebLayerTreeView is destroyed.

Done.

> 
> I'm not sure if the second is workable - we might pick up weird intermediate states if the compositor tries to draw from a texture id that is bound to an FBO as a color attachment in another context. So far in the WebCore compositor we've been ignoring this problem as other issues are currently higher priority, but if this is exposed as API that's a little less workable.

There's more than that that needs to be fixed for correct synchronization. Essentially we need to know when a compositing pass is done presenting the latest changes (so that you can have end-to-end synchronization). This is probably already problematic with out-of-thread compositor + plugins.
Right now, the only practical way is to look at the swapBuffers after the next swapBuffers.
Note however 2 things:
- The texture id is still propagated through the commit step. That means you can deal with a queue of textures and retiring/reusing them when you know it's not in use any more (2 swaps), and still get correct frames.
- The method used to generate those textures in the case of cross-process transport has some weak atomicity guarantees by the driver (i.e. the texture should be a complete frame).

> 
> R=me on the implementation stuff.
> 
> > Source/WebKit/chromium/src/WebExternalTextureLayerImpl.cpp:58
> > +void WebExternalTextureLayerImpl::paintContents(GraphicsContext& gc, const IntRect& clip)
> 
> nit: webkit style when an implementation doesn't use a parameter is to omit the name of the parameter. this avoids unused variable warnings on some compilers

Done.

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