[Public WebGL] using the same context with multiple canvases

Gregg Tavares (社用) [email protected]
Wed Dec 12 19:24:46 PST 2012

On Thu, Dec 13, 2012 at 1:13 AM, Tony Parisi <[email protected]> wrote:

> Long thread...
> I just wanted to throw my opinion in to mirror Ian's, that if we go down
> this path, it should work for 2d canvas drawing contexts as well. a) seems
> just as useful for 2D drawing and b) I would think that consistency with
> the other canvas context behavior would be highly desirable.

I agree it would be highly desirable to have consistency. But if you go
back in the thread it seems that Ian is not noticing that:

(a) In WebGL we need "creation attributes"
(b) The creation attributes need to be different for each "canvas" (either
on each cavnas or on some other object that can be associated with a
canvas). In other words i need to be able to create:

   a canvas that is only RGB vs RGBA (for GL compatibility and speed)
   a canvas that is anti-aliased vs not
   a canvas that is double buffered vs single buffered (for speed)
   a canvas that is composited assuming un-premultipled alpha vs
premultipled alpha (for GL compatibility)

(c) we need to be able to use 1 context that can work across all of those
types of canvases therefore those options can not be part of the context
but must be part of some other object (canvas or drawingbuffer)

The solution Ian has suggested so far does not cover those cases AFAICT.

> Tony
> On Wed, Dec 12, 2012 at 8:00 AM, Florian Bösch <[email protected]> wrote:
>> On Wed, Dec 12, 2012 at 4:45 PM, Vladimir Vukicevic <[email protected]
>> > wrote:
>>> does that getContext conceptually create a Drawingbuffer and call
>>> setDrawingbuffer on the canvas, as well as call bindDrawingbuffer on the gl
>>> context?
>> Yes
>>> Is Drawingbuffer webgl-specific, or a general abstraction? (Bikeshed
>>> note: we need a better name than "Drawingbuffer" IMO...). However, we'd
>>> still need to determine the types of contexts that it can be used with if
>>> it's general.  Maybe something like:
>> We've iterated this already on this thread in October, Frontbuffer was
>> worse, framebuffer is easily confused with framebuffer object,
>> drawingbuffer is actually a pretty good description.
>>> gl = new WebGLRenderingContext();
>>> db1 = gl.createDrawingBuffer({ depth: false });
>>> canvas.displayDrawingBuffer(**db1);  // setDrawingBuffer on the canvas
>>> seems like a weird API name, as we're really choosing what buffer to
>>> display; what buffer is drawn to is selected by the context
>> How about canvas.setDisplayBuffer(db1) ?
>>> twodee = Canvas2DRenderingContext();
>>> db2 = twodee.createDrawingBuffer({ doubleBuffer: true });
>>> canvas.displayDrawingBuffer(**db2);  // is this legal; canvas
>>> originally displayed a webgl buffer?
>> It should be legal in my opinion to attach an entirely different drawing
>> buffer to the same canvas. The context specificity goes with the drawing
>> buffer.
>>> db1 = new Drawingbuffer("webgl", { depth: false });
>>> db2 = new Drawingbuffer("2d", { doubleBuffer: true });
>> It's an interesting question, I might be wrong but people where arguing
>> for a context independent way to create drawing buffers (somewhere back in
>> october?).
> --
> Tony Parisi                             [email protected]
> CTO at Large                         415.902.8002
> Skype                                     auradeluxe
> Follow me on Twitter!             http://twitter.com/auradeluxe
> Read my blog at                     http://www.tonyparisi.com/
> Read my book! *WebGL, Up and Running*
> http://shop.oreilly.com/product/0636920024729.do
> http://www.amazon.com/dp/144932357X
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20121213/a9b941fa/attachment.html>

More information about the public_webgl mailing list