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

Re: [Public WebGL] Buffer size and viewport



On Mon, Jun 7, 2010 at 1:22 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
>
> ----- "Alan Chaney" <alan@mechnicality.com> wrote:
>
>> Hi Ken
>>
>> Kenneth Russell wrote:
>> >
>> >
>> > I assume you were using JOGL's GLJPanel. I was.
>>
>> > The issue you were likely
>> > running into with that component was that during some resizing
>> > operations the OpenGL context was destroyed and re-created, which
>> > generally forced the entire application to re-initialize. WebGL
>> > specifies that the OpenGL context is preserved during resizing
>> > operations, though it is necessary for the application to redraw.
>> >
>> I'm not arguing, but I assume you are referring to the content of Sec 2
>> Context Creation and Drawing Buffer Presentation?
>> Maybe its my fault, but I didn't interpret that section as explicitly
>> stating what you said above. In other words, please could you point me
>> to the wording that says that the context is preserved through
>> resizing?
>
> Note that this is currently not implemented in Firefox, as we create a new pbuffer context for each resize thus losing all previous GL resources.  We correctly track that now and throw errors when you try to use them in the future -- this is why things like MeShade don't work.  We'll likely switch soon to using FBOs for backbuffer rendering -- the main reason I'm not a fan of that is that it requires you to share resources with a parent GL context that's rendering to the screen, which means you don't get nice cleanup semantics by just destroying a GL context.  You have to make sure you delete all objects; I also worry about fragmentation issues with very long lived GL contexts (such as the parent context), with many contexts being created/destroyed that share resources with it... but we'll cross that bridge when we get there.

Would it be technically possible in your current implementation to
destroy the old pbuffer and create a new one, but continue to use the
same GL context?

What do you think about strengthening the wording in the spec around
this? Implementations that are incapable of handling a resize
operation gracefully could post a WebGLContextLost /
WebGLContextRestored event pair. We could state that implementations
that are incapable of handling a resize operation gracefully could
post a WebGLContextLost / WebGLContextRestored event pair(*), but that
it is strongly encouraged not to resort to this mechanism, and to
preserve the context's state during resizing.

-Ken

(*) WebGLContextRestored still needing to be specified of course.

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

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