On Oct 17, 2012, at 6:04 PM, Gregg Tavares (社用) <firstname.lastname@example.org> wrote:
I'd like to pursue this idea further that Florian brought up which is that, for drawing to multiple canvases, rather than share resources across contexts it would be much nicer to just be able to use the same context with multiple canvases. Something like
I like the idea of sharing a context across canvases, although I think there are issues with all the proposals that have been made in this thread.
What we're really talking about here is making it possible to have multiple framebuffers in the context be attached to canvases. In the WebKit implementation, the framebuffer associated with the canvas is just another FBO which we send out to the page as needed. These FBO's do have a specially prepared RenderBuffers, but that's all done at setup time.
For us the getContext call does two completely separate things. It creates an actual GL context, and then creates an FBO associated with the canvas for which the context was created. So separating those two functions would be easy.
So maybe we keep getContext() as a composite operation (and for compatibility). But then we create two new methods on the WebGLRenderingContext:
WebGLCanvasFrameBuffer createCanvas(HTMLCanvasElement, WebGLContextAttributes);
ctx = WebGLRenderingContext.createContext();
canvasFB = ctx.createCanvas(canvas, attrs);
Would be the same as:
ctx = canvas.getContext("webgl", attrs);
canvasFB = ctx.currentCanvasFrameBuffer();
This essentially inverts the current API, which I like because it avoids any changes to the HTMLCanvasElement API. It also avoids adding parameters to WebGLContextAttributes, which would not be a very strongly typed approach.
This would also allow us to create a WebGL context not associated with any canvas, allowing pure offscreen rendering.