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

Re: [Public WebGL] Context loss events and multi canvas rendering






On Fri, Mar 1, 2013 at 11:49 PM, Florian Bösch <pyalot@gmail.com> wrote:
Is losing a drawingbuffer the same as losing a context?

It depends on what you mean.

My point is this. Here's some code

function makeDrawingBufferWithImageInIt() {
   var gl = new WebGLRenderingContext();
   var db = new DrawingBuffer(gl, ....);
   gl.setDrawingBuffer(db);
   gl.....
   gl.drawArrays();
   return db;
}

var db = makeDrawingBuffferWithImageInIt();

I now have this DrawingBuffer with content in it. I have no reference to the context that created it anymore. The system will reclaim it supposedly. If the context is lost I'll have no idea that my DrawingBuffer's content was destroyed.  

Maybe that's okay? Maybe if you want to know that it was destroyed you need to watch for 'contextlost' on the context that created it? Maybe DrawingBuffer needs and event for contextlost? Maybe we need a new design? Maybe DrawingBuffers of a 'contentlost' event instead of a 'contextlost' event?


 


On Sat, Mar 2, 2013 at 8:32 AM, Gregg Tavares <gman@google.com> wrote:



On Fri, Mar 1, 2013 at 7:27 PM, Kenneth Russell <kbr@google.com> wrote:
Listening for context lost events on the context itself seems like the
best and most correct solution. If that's supported, would
DrawingBuffer need to support them? I don't think so.

The issue with DrawingBuffers is they can get lost too. Let's say you render to a DrawingBuffer once and keep it around. You pass that DrawingBuffer to another thread, maybe you're using it to draw into a canvas with drawImage. You get lost context. That lost context will arrive in the other thread. A thread you might have deleted at this point.

Maybe if you want to be able to recover from that situation you might be required to keep a reference to the context so you can know that the context was lost? But it seems like you'd like to be able to know from the DrawingBuffer? Or not. It's complicated either way :-(

 

Web workers seem to be able to actually listen for events (see the
onconnect message in
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#handler-sharedworkerglobalscope-onconnect
), so hopefully adding an event handling mechanism to
WebGLRenderingContext would not cause any issues with using WebGL in
workers.

-Ken


On Fri, Feb 22, 2013 at 2:31 PM, Gregg Tavares <gman@google.com> wrote:
>
>
>
> On Fri, Feb 22, 2013 at 5:00 AM, Florian Bösch <pyalot@gmail.com> wrote:
>>
>> I just noticed that the context loss events are registered on the canvas
>> rather than the context.
>>
>>
>> The newly proposed functionality of canvas independent contexts would make
>> it awkward to handle context losses (you will have to register the event on
>> every conceivable canvas and check that you don't double handle it).
>>
>> Would it be appropriate to extend the WebGLContext object with an event
>> handling mechanism so it can be handled per context?
>
>
> Yes, good point. They might need to be on DrawingBuffer too if we go that
> route.
>
>