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

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

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

>>> If you create a context using the constructor, you get a context and 
>>> it gets a backing store. If you then bind it to a canvas, the canvas 
>>> gets a separate backing store, and there's a method you invoke that 
>>> pushes the bits from the context to the canvas (this also happens 
>>> implicitly whenever the event loop spins). One way to distinguish the 
>>> two is to compare the results of drawImage() when passed a context vs 
>>> when passed a canvas. You can also see the difference between this 
>>> model and the shared bitmap model by drawing on the main thread and 
>>> then calling alert(); in the shared bitmap model the canvas will show 
>>> the drawing but in the split context model it will not.
>> That seems like a possible way to do it, yes.  It does involve twice the 
>> memory usage, right?
> I'm not sure, but I think so, yes. Or at least, another instance of the 
> bitmap buffer.
> Right now as far as I can tell you need two copies of the bitmap per 
> canvas: one for drawing on, and one for painting to the screen, so that 
> you don't get any flicker. In the model with disconnected contexts you 
> need one for drawing on, still, and one for the screen, and you may need 
> one for the canvas in practice, depending on how exactly you composite. 
> However, since it can't be drawn on other than just replacing the entire 
> image, it may be possible to get away with not actually having an entire 
> second copy all the time? I'm not sure.

Hopefully it can be spec'ed to be agnostic about buffering. In the iOS implementation there can be more than two buffers even. Once you're done drawing you hand the buffer to the system and from then on it's out of your hands. 

> On Sat, 10 Nov 2012, Chris Marrin wrote:
>>> What's the use case for getRenderingContext()?
>> I have a canvas, I want to know what context is currently associated 
>> with it.
> Why? What's the use case? What are you going to do with it?
> Note in particular that if the context is in another worker, and you're on 
> the main thread with the canvas, you're not going to be able to get the 
> actual context object anyway. The only place you can get the context 
> object is where you can set it, and since only you can set it, it seems 
> easy enough to keep track of it...

If I can get a reference to a canvas why can't I get its context so I can use it for drawing? Are you saying that I have to save it separately? That's how getContext is used today. After the first use (where the context is created) subsequent calls just return the same context. Why take such functionality?

>> I don't think it would be better to avoid a write-only API for the 
>> context.
> You think it would be better to have a write-only API for the context?

Boy, that could not have been written any less clearly! What I meant was that I DON'T want a write-only API. Sorry...

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl