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

Re: [Public WebGL] WebGL back buffer contents



On 2010-01-27 19:45, Kenneth Russell wrote:
On Wed, Jan 27, 2010 at 10:11 AM, Tim Johansson<timj@opera.com> wrote:
On 2010-01-27 18:51, Gregg Tavares wrote:

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

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

What you will want in most cases is to call something like:
canvas.width=foo;
gl.viewport(...);

Since that is the most common case it would make sense to me if it did that
viewport call automatically. You would have to write extra code in the
uncommon case that I want to keep the old viewport instead of having to
write extra code in the very common case that you want to change the
viewport to match the canvas.

I'm not saying you would never want to change the viewport, just that it
will be more common to render to the entire canvas. I don't think it should
be more difficult to do the common thing that most people will want to do
than it is to handle a special case.

In desktop GL the window size can change without the code causing the
resize, so they can't automatically change the viewport since the code don't
know when it will happen. In WebGL the script does know when the resize
happens so it would be possible to change it automatically.
In recent conversations with people at NVIDIA they were pretty adamant
that we not mess with the OpenGL state, in particular the viewport,
upon changing the canvas size. Gregg's render target example is a good
reason to not automatically call glViewport() behind the scenes.
Another point is that it isn't obvious exactly when the implicit call
to  glViewport() would be made -- whether it would be synchronous with
the setting of the width / height properties or whether it would
somehow be done lazily, before the first draw call after the canvas is
resized.

I used to think that doing this automatically would be a good idea but
because of the semantic details I don't any more.


We recently said that resizing should clear the canvas, which means we have to mess with the gl sate anyway. We will at least need to change bound FBO to 0 and disable scissor testing. Does it not qualify as messing with the state if we mess with it and then try to restore it?


I agree that in the case of rendering to an FBO you would not want to change the viewport automatically, but I would rather have apps handle that case themselves and set the viewport back than have apps handle the most common case themselves. If the spec says that changing width or height behaves as if it calls viewport as soon as the width/height attribute is changed it would be clear what will happen. I would not even call it messing with the state as it just does what the app tells it when the app tells it to, that is change the size of the buffer and the viewport.

We could also do something more magical and say that if you have not changed the viewport yourself it will automatically change. If you ever did call viewport automatic viewport adjustment is disabled. That way it would never change the viewport for apps actually modifying the viewport and it would just work for apps who does not care about the viewport. So initial value for viewport would be "automatic", but there is no way to set it back to "automatic" if you change it yourself.

//Tim

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