[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 #23 from James Robinson <jamesr at chromium.org>  2010-09-01 16:08:13 PST ---
(In reply to comment #18)
> (In reply to comment #17)
> > Thanks for looking through this patch.  I'll do my best to address all the line-by-line comments.
> > 
> > The point you make about the FBO treatment is a valid one, Chris.  We'll also want to generalize this in order to support multisampling.  Here's what I propose to make this more general:
> > 
> > 1.) No new functions on GraphicsContext3D
> > 2.) CanvasFramebuffer adopts a more general interface to look something like:
> > 
> > create(SharedContext3D*, IntSize)
> > bind()
> > publishToPlatformLayer(PlatformLayer*)
> > publishToTexture(unsigned)
> > 
> > and not expose any specifics about what the FBO binds to.  Then implementations can bind a CanvasFramebuffer to either a color texture or a RenderBuffer and deal with the details of how to expose the rendering results to either a PlatformLayer (for compositing) or a texture (to draw the rendering results in another canvas).  The specifics of allocating a compositing target (texture, CALayer, etc) and doing the copy/blit/resolve will be handled by each platform.
> 
> This looks pretty good. Since CanvasFrameBuffer is intimately tied to SharedContext3D, perhaps its ctor should not be public and there should be a createFramebuffer method on SharedContext? That would make the relationship more clear I think. I like the model of the context vending the buffer you'll be drawing into.
> 
> 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 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.

> 
> 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.
> 
> 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 :).

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