On Fri, Jan 29, 2010 at 1:13 AM, Carl van Heezik <carl@microcan.nl> wrote:

I agree with Patrick and others that al these behind the back calls typically mess things up. As programmer you need a callback when the canvas resizes. Then the programmer decides if it need to adjust the viewport setting to get the transform right. The current WebGL works different than existing OpenGL implementations because you have to rescale the backbuffer as well. On Windows this was automatic.

- rescale backbuffer (what is the name of the function call ?)
- adjust viewport (viewport transform)
- adjust projection transform to get the aspect ratio right

I did some test with the window.onresize but this does not work in all cases. If the window does't resize but the canvas does e.g. by some CSS rule you do not get a callback. This means you have to set up code for every case that resizes the canvas. I would prefer a canvas.onresize that gets called whenever the canvas changes size, this can save you a lot of coding and debugging.

I agree, it seems like best solution is element.onresize (for any element, not just canvas). But that's an HTML5 issue, not a WebGL issue.

For the most part, 99% of apps will work with window.onresize because they'll either have a fixed aspect ratio for the canvas or responding to window.onresize will be enough. For those small percentage of apps that this doesn't cover we should lobby the HTML5 people to add element.onresize

Best regards,

Carl van Heezik

Op 28 jan 2010, om 22:04 heeft Patrick Baggett het volgende geschreven:

I've been watching this thread, and I'd say that most developers who are used to XWindows and Win32 environments know that when there is a resizing of the window, you need to call glViewport(), and I think the semantics Ken described mirror that familiarity. When in doubt, I think the simplest solution should be the best, and Ken is right, describing the semantics of an automatic-resize-but-only-if-you-dont-do-glViewport (and making sure the implementation does so properly) is just more difficult than it needs to be. It also doesn't take into account that the author could call a 3rd party piece of code that does glViewport() and then disables this automatic behavior, and the author is left wondering why automatic viewport handling doesn't work, etc. etc. Law of least surprises, anyone?

That being said, I think that automatic calls of glViewport() are just wrong. The viewport is just how NDC are transformed, and have little to do with the actual back buffer contents or dimensions -- they are GL state, not part of the underlying windowing system state, therefore it should not be the windowing system's [i.e. canvas in this case] job to modify them. I think that just crosses some system separation line.

I use glViewport() to draw a subrect in 3D and use the remaining space for 2D elements. I would not want an implementation to waste it's time calling glViewport() for me, just so I can call it with what I really want, or for that matter, to clobber what I've done.

Patrick Baggett

On Thu, Jan 28, 2010 at 1:30 PM, Kenneth Russell <kbr@google.com> wrote:

On Thu, Jan 28, 2010 at 10:39 AM, Tim Johansson <timj@opera.com> wrote:
> On 2010-01-28 18:27, Chris Marrin wrote:
>>
>> On Jan 28, 2010, at 1:43 AM, Tim Johansson wrote:
>>
>>>>>
>>>> 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?
>>
>> Why would we have to change the FBO or scissor state? If you have an FBO
>> set, then changing the size of the drawing buffer doesn't affect it, does
>> it?
>>
> When resizing the canvas what you have to do is first resize the backbuffer
> which is probably an FBO or pbuffer (unless you created a bigger backbuffer
> than you needed to avoid having to resize it).
>
> After that you need to clear the backbuffer, otherwise resizing and drawing
> a small triangle could give undefined results. Assuming you want to call
> glClear to clear the backbuffer you have to switch FBO or you will clear the
> applications FBO rather than the backbuffer.
>
> If the application has a scissor set and you clear without disabling scissor
> test you will only clear the area defined by that scissor rect, which might
> not be the entire new backbuffer.
>
> Changing the size of the drawing buffer will not affect the FBO, but it will
> affect the drawing buffer in a way that is difficult to do without changing
> the GL state.
>
>>>
>>> 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.
>>
>> I'm not sure of your concern. What is the problem with requiring that the
>> author calls ctx.viewport() after changing the width and height? The author
>> has to know about viewports and keeping track of them. So why is that an
>> issue?
>>
> If you have to call viewport every time you resize the canvas then yes, you
> have to know about it. If it changes automatically you would not have to
> know about viewports if you just want to render to the full canvas and don't
> want to change the viewport.
>
> It is not a big issue, just seems like an inconvenience that can be fixed.

It's going to be very complicated to explain the semantics to
developers if we sometimes automatically resize the viewport and
sometimes don't. Given the lack of per-element resize events, I think
we should be consistent and require the developer to always set the
viewport. Most developers will probably just set the viewport to
(canvas.width, canvas.height) in their draw callback, which will allow
them to handle resizing easily, and in one place.

-Ken

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

Re: [Public WebGL] WebGL back buffer contents