On Thu, Jan 28, 2010 at 10:39 AM, Tim Johansson <email@example.com
> 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
>>>> 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
> 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
> 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.