[Webkit-unassigned] [Bug 44926] Multiple accelerated 2D canvases should be able to use the same GraphicsContext3D

[bugzilla-daemon at webkit.org]

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





--- Comment #30 from Chris Marrin <cmarrin at apple.com>  2010-09-02 14:46:07 PST ---
(In reply to comment #28)
> ...
> > I think the closer we can keep this to the WebGL model the better. We of course need to deal with the optimization of a single shared context, but that can all be done up in the SharedContext3D like you have in your latest patch (which looks good).
> > 
> 
> I think this could work.  I don't think it would be an improvement, however.  The WebGL model is pretty inflexible since it ties up the compositing logic for the element with the behavior of the element.  I think it's cleaner for the canvas-specific logic (i.e. the SharedContext3D, ContextRenderingContext2D, etc) to be concerned with taking commands from javascript and producing rendering results in a DrawingBuffer and not worry about compositing at all.  When the layer is composited then the compositor only needs to know where the rendering results are, it doesn't need to be aware of the rest of the canvas stack.  The DrawingBuffer has to be aware of both, of course, so that it can take the rendered results and put them in a layer.
> 
> One concrete problem with the WebGL model is that since the GraphicsContext3D owns the PlatformLayer directly, the compositor can't decide when to create or destroy the PlatformLayer itself.  If a page is loaded in a background tab then it would be really handy for the compositor to ditch all the platformlayers and their associated backing stores and just let each canvas continue rendering to a DrawingBuffer.

But if you had such a capability then the GraphicsLayer would have to know about more classes, GraphicsContext3D in the case of WebGL, and DrawingBuffer in the case of accelerated Canvas 2D. I don't think it's valid to say that giving GraphicsLayer control of the platform layer is better because you conserve resources. The PlatformLayer might not be the expensive part. It might be somewhere in the GraphicsContext. If we wanted to conserve resources it would be best done with a "you're going into the background, please conserve your resources" call to the various GraphicsContext3D and SharedContexts.

Your implementation has already grown the GraphicsLayer call with the setContentsToCanvas2D method. And it would have to grow it again for each new accelerated content type, adding another context object that GraphicsLayer needs to know about, too.

The current model is the way it is because it's the renderer of the content (e.g., GraphicsContext3D, DrawingBuffer) that knows what the requirements for the PlatformLayer are, so it should be that renderer where the PlatformLayer is vended. This model comes from the implementation of accelerated video rendering. The movie player vends a PlatformLayer that it has created specifically for rendering movies into. I really think we should stick with that model.

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