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

Re: [Public WebGL] WebGL back buffer contents

On Wed, Jan 27, 2010 at 9:35 AM, Tim Johansson <timj@opera.com> wrote:
On 2010-01-27 18:22, Gregg Tavares wrote:

On Wed, Jan 27, 2010 at 12:28 AM, Tim Johansson <timj@opera.com <mailto:timj@opera.com>> 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.


                   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

                      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.


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


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 code

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 AFAIK

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?


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: