[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 #24 from Chris Marrin <cmarrin at apple.com>  2010-09-01 17:41:34 PST ---
(In reply to comment #23)
>...
> > How are you creating the PlatformLayer? Doesn't the SharedContext need to vend that as well? Did I miss the call that does that?
> 
> The PlatformLayer is created by the platform-specific implementation of GraphicsLayer::setContentsToCanvas2D().  It's made aware of the DrawingBuffer at creation time and whenever the compositing layer tree is regenerated.  PlatformLayer creation and initialization is inherently platform-specific (as the name of the type would imply).

I see that. That seems less than ideal though because it is very specific to Canvas 2D. It also has different ownership that WebGL, where the GraphicsContext3D owns the PlatformLayer. Seems like it would be better if SharedContext3D just had a factory for PlatformLayers that you could then send along to GraphicsLayer::setContentsToCanvas(). I don't see any logic in setContentsToCanvas2D that make it necessary for GraphicsLayer to know it's a 2D Canvas, or have any knowledge at all about DrawingBuffer. Committing the rendered image to the PlatformLayer will still require a call to publishToPlatformLayer() and that all happens up in the Canvas logic.

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 left the DrawingBuffer::create() as a static function on DrawingBuffer so that it's easier to find the implementation.  There will eventually be a number of platform-dependent implementations of this create and I think it'd be better if the various DrawingBufferXXX.cpp files contained only DrawingBuffer:: functions instead of having a function declared on SharedContext3D.
> 

Fair enough...

> > 
> > Also, I'm not sure it's appropriate to call this a Framebuffer. It's really an FBO, plus Renderbuffers, plus context info. So maybe calling it a DrawingBuffer would be more appropriate. That's the term we use in the WebGL spec and it really refers to the combination of all these things. Also, using the term "Canvas" here is misleading. this is more general that just Canvas.
> 
> I like DrawingBuffer a lot, the latest patch uses this name.

Cool.

> > 
> > And while I'm being the pedantic naming police, SharedContext3D would be more accurately named SharedGraphicsContext3D.
> 
> That would work, but I don't think it adds any extra information since there's only one possible sort of "...Context3D" in webkit.  I've thus left it as SharedContext3D.  I can change it if you feel strongly but it's a lotta letters to type :).

Yeah, I thought about that. But when I typed it, it didn't look that bad. I'm concerned about other uses of the term "context", which is pretty generic. It's only 8 extra letters and one is an 'i' which is really narrow :-)

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