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

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



>From a practical standpoint I don't think the drawing buffer will ever
be lost without its associated rendering context (either 2D or WebGL)
being lost. Gregg, what do you think?


On Mon, Mar 4, 2013 at 12:42 PM, Florian Bösch <pyalot@gmail.com> wrote:
> I think it only makes sense to have another event (than context lost on the
> context) if you can lose the drawing buffer alone (without losing the
> context). If you can only lose the drawing buffer as a result of a context
> loss, then I don't think a separate event makes sense.
>
>
> On Mon, Mar 4, 2013 at 9:39 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> These are good points. Conceptually the drawing buffer's contents
>> could be lost independently from the WebGL context, but in practice, a
>> DrawingBuffer's backing store (color buffer, etc.) will be allocated
>> in the same OpenGL share group as the WebGL context. Therefore if the
>> WebGL context is lost via ARB_robustness or EXT_robustness, the
>> drawing buffer's contents will always be lost.
>>
>> Do you think it is worth specifying another "content lost" event,
>> having it apply to DrawingBuffers, and trying to have it apply to
>> canvases as well? Or should the context lost event against the
>> WebGLRenderingContext be enough of a hint for application authors that
>> they'll need to push another DrawingBuffer into the output canvas? For
>> generality I agree that a "content lost" event should be specified,
>> but I think the same result can be reached just by holding on to the
>> contexts and watching for context lost.
>>
>> -Ken
>>
>>
>>
>> On Sat, Mar 2, 2013 at 12:08 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> > So the canonical "context lost" is not what you mean by losing a drawing
>> > buffer (which is the system reclaiming it for some reason).
>> >
>> > Context lost has a meaning for a context because it means all other
>> > resources by that context have become null and void. Losing your
>> > drawingbuffer does not mean that your contexts resources are now null
>> > and
>> > void, hence the same name should probably be avoided for whatever event
>> > you
>> > want to issue. More to the point:
>> >
>> > - If you still have the context used to create the drawing you can
>> > redraw on
>> > drawingbuffer restored
>> > - If you don't have the context anymore, there's nothing you can do
>> > anyways
>> > if you drawingbuffer lost
>> > - drawingbuffer lost would not have an impact on whatever context is
>> > attached to it in terms of the validity of that context
>> > - context lost would not have an impact on whatever drawing buffer its
>> > connected to in terms of the drawing buffer being valid
>> >
>> >
>> > On Sat, Mar 2, 2013 at 8:57 AM, Gregg Tavares <gman@google.com> wrote:
>> >>
>> >>
>> >>
>> >>
>> >> 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.
>> >>>>> >
>> >>>>> >
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>
>

-----------------------------------------------------------
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
-----------------------------------------------------------