[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 #31 from James Robinson <jamesr at chromium.org>  2010-09-02 17:10:22 PST ---
For the record, I originally wrote this patch following WebGL's method of PlatformLayers.  It quickly got disgusting, which led to this approach.

In WebGL, the WebGLRenderingContext has a 1:1 relationship with a GraphicsContext3D.  Each GraphicsContext3D holds a reference to one PlatformLayer.  On the mac PlatformLayer is a typedef for CALayer.  The GraphicsContext3D holds a RetainPtr<WebGLLayer> where WebGLLayer is a subclass (indirectly) of CALayer.  The layer is eagerly constructed and held for the lifetime of the GC3D.  It's nearly the same for Chromium, except that the pointer is a RefPtr<LayerChromium> held on GraphicsContext3DInternal and it is lazily created on the first access rather than eagerly.  When WebGL content is composited RenderLayerBacking::updateGraphicsLayerConfiguration() grabs a pointer to the PlatformLayer from the GraphicsContext3D and passes it to GraphicsLayer::setLayerContentsTo..().  Then the GraphicsLayer implementation grabs another reference to the layer (on mac by storing it in a RetainPtr<CALayer>, in chromium by storing it in a RefPtr<LayerChromium).  The reason for the ref counting d
 ance is that the lifetime of the WebGL canvas and the compositing layer are inherently decoupled.  The compositing layer owning the contents layer is generally created after the WebGL canvas and may be destroyed before or after the canvas.  Thus both have to keep a reference to the PlatformLayer.

For 2d canvas, we could (and I initially did) do a similar sort of dance where both the canvas logic and the compositor maintain a reference to the PlatformLayer.  The question is then who holds the reference outside of the compositor.  This can't be retained by the SharedGraphicsContext3D, because there is no 1:1 mapping between a SharedGraphicsContext3D and a canvas.  The PlatformLayer could be held by the CanvasRenderingContext2D, but that means adding a bunch of #if PLATFORM() gunk to CanvasRenderingContext2D in order to manage its lifetime.  Conceptually the CanvasRenderingContext2D should not need to know anything directly about compositing anyway.  The other possibility is to hold the PlatformLayer on the DrawingBuffer.  This ends up being strange as well since the DrawingBuffer can be reset by the page, so it doesn't live for as long as a CanvasRenderingContext2D or the compositing layer.

What I decided on here is having the DrawingBuffer be refcounted by the CanvasRenderingContext2D and the compositing layer and have the PlatformLayer management done completely on the compositor side.  This is analogous to how Image and contents layers are managed currently.  I think it's much cleaner to have a reference counted DrawingBuffer maintained on both sides since a DrawingBuffer is a completely cross-platform concept, unlike a PlatformLayer.  The other advantage is that we only have to create PlatformLayers when actually compositing a canvas.  If this followed the WebGL/mac pattern, we would have to create a PlatformLayer for canvases that aren't even in the page.  It's pretty common to create many offscreen 2d canvases to use as intermediate results (although I imagine this is less common in WebGL).

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