[Public WebGL] WebGL back buffer contents

Gregg Tavares [email protected]
Wed Jan 27 09:51:16 PST 2010

On Wed, Jan 27, 2010 at 9:35 AM, Tim Johansson <[email protected]> wrote:

> On 2010-01-27 18:22, Gregg Tavares wrote:
>> On Wed, Jan 27, 2010 at 12:28 AM, Tim Johansson <[email protected] <mailto:
>> [email protected]>> wrote:
>>    On 2010-01-27 01:45, Chris Marrin wrote:
>>        On Jan 26, 2010, at 3:37 PM, Oliver Hunt wrote:
>>            On Jan 26, 2010, at 3:28 PM, Chris Marrin wrote:
>>                On Jan 26, 2010, at 10:00 AM, Vangelis Kokkevis wrote:
>>                    ...
>>                    I think we should settle on having the contents of
>>                    the WebGL drawing
>>                    buffer be persistent, like the 2D context. Having
>>                    a completely new
>>                    back buffer potentially swapped in unexpectedly
>>                    will be too surprising
>>                    to the programmer.
>>                    -Ken
>>                    I like that idea although I'm not sure how we
>>                    would handle resizing of drawing surface.  What's
>>                    the expectation then?
>>                Here is what the Canvas element 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.
>>                       When the canvas is initialized, its bitmap must
>>                be cleared to transparent black.
>>                That seems like an appropriate definition for us.
>>            My only concern with this exact definition is that the 2d
>>            canvas is completely reset - all state is clobbered,
>>            applying the same logic to webgl would imply that all
>>            shaders, etc would be unloaded as well, which seems a
>>            little extreme.
>>        Yeah, I didn't fully read the "and any associated contexts"
>>        part. I think that in the past we agreed that we should not
>>        even mess with the viewport coordinates on a size change. So
>>        perhaps better wording would be:
>>               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 must be cleared to transparent black.
>>               Furthermore upon creation of the context its initial
>>        state shall be as described in the OpenGL ES 2.0
>>               specification [GLES20].
>>               Setting the width and height attributes after
>>        initialization shall not change the context state.
>>    I thought we said we should change the viewport when resizing, or
>>    maybe that changed later and I missed it?
>>    I think it would be less confusing, at least in the most common
>>    case, if the viewport did change on resize.
>> http://www.khronos.org/bugzilla/show_bug.cgi?id=245
>> Setting the viewport automatically could cause problems.
>> Here's one example.
>> --psuedo code-
>> // Set to render to a render target
>> ...
>> // Set the viewport to match the render target
>> gl.Viewport(/* rendertarget dimensions */)
>> // Change the dimensions of the canvas
>> canvas.width = new_width;
>> canvas.height = new_height;
>> // Render something to render target.
>> // The user should not expect the viewport setting to have changed
>> gl.drawElements(...);
>> -------------
>> Just to clarify. There are 2 dimensions to a canvas
>> canvas.width and canvas.height set the dimensions of the back buffer.
>> These can only be set by code.
>> canvas.style.width and canvas.style.height set the dimensions to display.
>> These can change without code by setting them to percentages.
>> There is no case where the browser is going automatically to change the
>> back buffer dimensions. Only user code can do that and so user code can set
>> the viewport.
> Yes, I am aware of that. That also means that the viewport would never
> change without the script resizing the canvas though, and if the script is
> doing something special (such as rendering to an fbo) it can handle that
> before or after causing the resize.
> Rendering directly to the canvas is probably the most common case, and
> having that "just work" without special handling would IMO be better and
> probably cause less confusion in total. As long as it is documented that the
> viewport will change on resize I don't think it will be such a big problem.
> The 2d context clears all state on a resize and that has not cause so much
> problem.

I'm getting lost. If the canvas can not be resized except by user code then
why does the viewport need to automatically be updated?  I could see an
argument if the browser could magically resize the back buffer but it can't.
I just want to make sure the 2 resize cases are not getting confused.

Case #1: Resizing the back buffer (ie. canvas.width) can only be done by

Case #2: Resizing the canvas element display size (ie. canvas.style.width)

It's only case #1 that has anything to do with the viewport setting and case
#1 can only be done in code.

So, why should

canvas.width = new_width;

suddenly change the viewport settings? This doesn't happen in DesktopGL

It would basically be making this code invalid

// Set the viewport to draw to the top corner of the screen
gl.Viewport(0, 0, new_width / 2, new_height / 2);
canvas.width = new_width;
canvas.height = new_height;

Why should that code be invalid?

> //Tim
> -----------------------------------------------------------
> You are currently subscribe to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100127/3eebcc89/attachment.html>

More information about the public_webgl mailing list