[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL back buffer contents
On Jan 28, 2010, at 10:39 AM, Tim Johansson 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
>>>> 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.
But these are all implementation details. It's true that in our implementation we use an FBO, but that is not apparent to the user and cannot affect the apparent state the user sees. So if the user has their own FBO set with some scissor state and we need to resize the drawing, when all is said and done, the state has to be set to the user's FBO and scissor buffer. We can change all that to implement the resize as needed, but we need to set it back before we're done. Or would could see that a user FBO is set and avoid changing the drawing buffer's FBO until the user changes back to the system FBO. But in the end the state must not change from what the user has set.
>>> 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.
But then it wouldn't be OpenGL ES, which does no automatic viewport setting. In this case I don't think we should deviate from that.
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: