[Public WebGL] using the same context with multiple canvases

[Ian Hickson]

On Tue, 18 Dec 2012, Gregg Tavares (社ç~T¨) wrote:
> On Tue, Dec 18, 2012 at 3:30 AM, Ian Hickson <ian...@> wrote:
> > On Mon, 17 Dec 2012, Gregg Tavares (社ç~T¨) wrote:
> > > On Fri, Dec 14, 2012 at 5:08 AM, Ian Hickson <ian...@> wrote:
> > > > On Thu, 13 Dec 2012, Gregg Tavares (社ç~T¨) wrote:
> > > > > >
> > > > > > Is this something that would make sense as arguments to 
> > > > > > setContext()?
> > > > >
> > > > > It doesn't seem like the appropriate place since they are 
> > > > > "creation" parameters and since for an animated app with 
> > > > > multiple canvases you're going to be calling setContext once per 
> > > > > canvas per frame.
> > > >
> > > > They don't have to be creation, right? I mean, you have multiple 
> > > > contexts and you have multiple canvases, you're not going to be 
> > > > necessarily creating anything after that, just binding a context 
> > > > to a canvas and drawing. If the settings are specific to a 
> > > > particular context/canvas binding, then setContext() seems the 
> > > > right place...
> > >
> > > How does this help us in workers where we also want to be able to 
> > > create some object that represents what's being drawn to and we want 
> > > to be able to create multiple of them, draw to them with 1 context, 
> > > and have each have different attributes?
> >
> > setContext is on the CanvasProxy object you have in workers also.
> 
> My understanding of CanvasProxy is it's something you create in the main 
> thread from a Canvas. Not something the worker creates.

It's created for a specific canvas, then sent to the worker.


> We're asking for something a worker creates, no relation to the main 
> page whatsoever.

I still don't see why the context can't do this, but ok.

I really don't understand why, given that you have a scene graph object 
and a place for the scene graph to be rendered to, you feel it's important 
to have a middle-man object.

I understand that there is a concern that authors will accidentally change 
the settings and that changing the settings used in a particular context/ 
canvas pair is expensive. But I don't see how a middleman object would 
help. If an author could accidentally use different settings when binding 
a context to a canvas, why couldn't an author accidentally use a different 
middle man object?

If the settings are described by an object, why wouldn't the author pass 
the same object each time to setContext()?

That is, instead of 

   canvas1.setContext(webgl1, { setting1: 'a', setting2: 'a' });
   // ...
   canvas2.setContext(webgl1, { setting1: 'b', setting2: 'b' });
   // ...
   canvas1.setContext(webgl1, { setting1: 'a', setting2: 'b' }); // oops
   // ...
   canvas1.setContext(webgl2, { setting1: 'c', setting2: 'c' });
   // ...

...why wouldn't authors do:

   var canvas1webgl1 = { setting1: 'a', setting2: 'a' };
   var canvas2webgl1 = { setting1: 'b', setting2: 'b' };
   var canvas1webgl2 = { setting1: 'c', setting2: 'c' };
   canvas1.setContext(webgl1, canvas1webgl1);
   // ...
   canvas2.setContext(webgl1, canvas2webgl1);
   // ...
   canvas1.setContext(webgl1, canvas1webgl1);
   // ...
   canvas1.setContext(webgl2, canvas1webgl2);
   // ...

In fact, why would one canvas ever be used with two different contexts 
with different settings? Can the settings just be put on the canvas (or 
canvas proxy) directly?

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