[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] using the same context with multiple canvases



This doesn't work for WebGL

   var context = new WebGLRenderingContext();
   canvas1.setContext(context)   

It's missing the creation attributes for the canvas (alpha? depth? stencil? anti-alias? preserved? premultiplied?)




On Sun, Nov 11, 2012 at 1:12 AM, Chris Marrin <cmarrin@apple.com> wrote:

On Nov 9, 2012, at 3:33 PM, Ian Hickson <ian@hixie.ch> wrote:

I've been looking at this in the context of the 2D context and cross-worker canvases.

I like the idea described in this thread regarding being able to construct a rendering context independent of a canvas ("front buffer"). Rather than having the ability to bind a context to a canvas be a property of the context, though, I think it would make more sense to have it be a feature of the canvas. As in:

   var context = new WebGLRenderingContext();
   ...
   canvas1.setContext(context);
   // do whatever to update canvas1
   ...
   canvas2.setContext(context);
   // do whatever to update canvas2

Calling getContext() on a canvas after setContext() has been called would fail.
Calling setContext() on a canvas after getContext() has been successfully used would fail.

Yes, putting this on Canvas would be more sane. My proposal was simply trying to avoid changes outside WebGL. My one issue with this approach is that having getContext() fail after setContext() is confusing. Really getContext() becomes a misnomer used this way. It is really createContext() or something similar. But since we can't change that, maybe we can create a new pair of calls:

canvas.setRenderingContext(context);
context = canvas.getRenderingContext();

Then we could leave getContext() alone and use it for legacy purposes. But I agree that, in this scenario, getContext should fail if you've ever called setRenderingContext().

-----
~Chris Marrin
cmarrin@apple.com