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

Re: [Public WebGL] WebGL context resize / canvas redraw

On Thu, Feb 25, 2010 at 11:54 AM, Kenneth Russell <kbr@google.com> wrote:
On Thu, Feb 25, 2010 at 11:38 AM, Kenneth Russell <kbr@google.com> wrote:
> On Thu, Feb 25, 2010 at 11:06 AM, Philip Taylor <excors@gmail.com> wrote:
>> On Thu, Feb 25, 2010 at 6:17 PM, Kenneth Russell <kbr@google.com> wrote:
>>> On Thu, Feb 25, 2010 at 6:04 AM, Carl van Heezik <carl@microcan.nl> wrote:
>>>> Chris,
>>>> context resize
>>>> I noticed some differences in the WebGL implementations in Webkit and
>>>> Minefield.
>>>> When you resize the canvas the following instructions are enough to resize
>>>> the
>>>> rendering context in Webkit.
>>>>     canvas.width   = canvas.clientWidth;
>>>>     canvas.height  = canvas.clientHeight;
>>>> I think in Minefield you lose the shaders and other buffers because it only
>>>> works
>>>> when I recreate the shader program and buffers. What behavior is supposed to
>>>> happen when you change the canvas size?
>>> This is a bug in Minefield. Resizing the canvas should not destroy the
>>> context, only reallocate the back buffer for the canvas.
>> HTML5 says:
>>  "When the canvas element is created, and subsequently whenever the
>> width and height attributes are set (whether to a new value or to the
>> previous value), the bitmap and any associated contexts must be
>> cleared back to their initial state and reinitialized with the newly
>> specified coordinate space dimensions."
>> so the WebGL context ought to be reset to its initial state (the same
>> as if you replaced the <canvas> element with an entirely new one).
>> Resources that are generated by the context but are not part of the
>> context (in the 2d case these are CanvasGradient, CanvasPattern,
>> ImageData, etc - you can create them from one context, and then draw
>> them on a totally different canvas's context, since they have an
>> independent existence) won't get reset, though.
>> Is WebGL compatible with this definition? (I've not looked carefully
>> but it seems it may not be). If not, and if there's good reasons to be
>> incompatible, then it'd be good to get HTML5 updated so it allows this
>> resetting behaviour to be specified by each context.
> WebGL is compatible with this definition. Per section 2.2 of the draft
> spec, the color, depth, and other buffers are cleared upon resize. Per
> section 2.3, the OpenGL viewport state is *not* touched. No other
> modifications to the OpenGL state, nor to any created objects like
> textures, should occur as a result of resizing the canvas.

Gregg pointed out that I misunderstood the HTML5 statement. The
requirement that the contexts (rather than the backing bitmaps) are
cleared back to their initial state is incompatible with WebGL. We do
not want to have to throw away the OpenGL context or otherwise touch
its state if the canvas is resized. This is effectively the same as
generating a context lost event and would be traumatic to the app.

I think section 2.2 of the WebGL spec states the behavior pretty
clearly. Minefield should be changed to follow it.

I think what Philip was pointing out is that this requires the HTML5 spec to be updated to state that it's up to the particular type of context whether or not its state is reset when the size changes.


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