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

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



On Sun, 11 Nov 2012, Brandon Jones wrote:
> On Nov 11, 2012 10:47 PM, "Ian Hickson" <ian@hixie.ch> wrote:
> >
> > When would you want one canvas done one way and another a different 
> > way, for the same rendering context?
>
> There's several reasonable explanations for having differing properties 
> per-canvas. Consider Gregg's example of a Maya like tool: it would be 
> sensible to request an antialiased canvas for the main editing view, but 
> for performance reasons request a non-antialiased canvas for a texture 
> preview widget.

The viewport dimensions are on the context currently, right? Why not put 
these on the context as well, and just have the author update them when 
they switch canvas?


On Mon, 12 Nov 2012, Gregg Tavares (社~T) wrote:
> 
> How about
> 
>    db = new DrawingBuffer(creatationAttrubites);
> 
> for gl
> 
>    gl.bindDrawingBuffer(db);
> 
> for canvas 2d???
> 
>    ctx.setDrawingBuffer(db);

Why have two different APIs?


> > Today, when does a WebGLRenderingContext "commit" or "draw" to the 
> > currently assigned canvas? Is it just when the event loop spins, or is 
> > there an explicit "paint a frame now" method?
> 
> It's currently supposed to be when the current event exits IMO but the 
> spec is ambiguous saying something about when it's compositied which 
> means it's browser specific if other events come by before compositing 
> happens.

So you if drawImage() a GL canvas half-way through a script, it draws the 
previous image state (as it stood the last time the event loop span), not 
the mid-way state like the 2D canvas?


I'm not a fan of a DrawingBuffer object because it's yet more indirection, 
and we have a pile of indirection here already with all the cross-worker 
canvas stuff. I could see having the contexts implicitly have their own 
drawing buffer while they aren't bound to a canvas, and having these 
buffers be reset (along with state, in the 2D world, though not in GL) 
when you bind/unbind, but I don't see why we'd want to explicitly have an 
object for this.


If GL doesn't need in-between state (i.e. if drawImage() for GL always 
draws the last committed image, not the current state), and if we're ok 
with using this model for 2D as well when in a worker, I think the 
simplest solution is:

- have two ways to get a context: via getContext(), and via a constructor

- the getContext() method is the current method, it's always fixed to the 
same canvas it was created from, and can't be moved; drawImage() in the 2D 
world gets the current state

- the constructor gives you back a context with its own implicit backing 
store; you can set its dimensions dynamically using constructor arguments 
and can change the dimensions later on the context itself; this object can 
be bound to a canvas (or CanvasProxy for workers) later

- when you bind a context to a canvas, it blows away its bitmap (and 
state, for 2D, though not for GL), and drawing commands start going to the 
canvas. The bitmap is now just the canvas bitmap; drawImage() and, in 2D, 
getImageData(), take the last committed image; you can commit the drawing 
commands to that bitmap using commit() or spinning the event loop

- drawImage() now additionally takes a context, but it always refers to 
whatever the context's bitmap looks like (the last committed image, 
except for the case of getContext('2d') since that implicitly commits 
after each command, as noted above)

- the way to spec this is probably by having a virtual "current" bitmap 
that all commands go to, but which is not directly accessible from JS

- binding a new context to a canvas unbinds the previous context bound to 
it, at which point it goes back to just having an implicit bitmap

- the implicit bitmap can be implemented lazily; it's not needed unless 
someone tries to read from it at which point you just need to execute the 
commands that were queued against it when it was last commit()ted.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'