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

Re: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size?



On Sep 24, 2010, at 4:31 PM, Kenneth Russell wrote:

> On Fri, Sep 24, 2010 at 4:17 PM, Gregg Tavares (wrk) <gman@google.com> wrote:
>> 
>> 
>> On Fri, Sep 24, 2010 at 4:10 PM, Kenneth Russell <kbr@google.com> wrote:
>>> 
>>> On Fri, Sep 24, 2010 at 8:58 AM, Chris Marrin <cmarrin@apple.com> wrote:
>>>> 
>>>> I've read over the thread and I agree that we can't hide the actual size
>>>> from the author. But I don't think we can change canvas.width and
>>>> canvas.height either. Read/write attributes in the DOM are typically not
>>>> changed by the system from what the author set. It might even be prohibited
>>>> in the DOM spec.
>>>> 
>>>> If so, I think we can deal with it cleanly. We already have a context
>>>> error event which we can use to notify the author that the context could not
>>>> be created and we can indicate that it was because the size was too large
>>>> and return the max width and height so the author can make another try. We
>>>> can also specify a minimum supported canvas size (1024x1024 or something) so
>>>> authors can avoid having to handle the event if they stay within that size.
>>> 
>>> If the author has already fetched a WebGLRenderingContext from the
>>> canvas before resizing it then this would need to be a context lost
>>> event, not a context creation error event.
>>> 
>>> Despite the fact that delivery of this event is traumatic to the app,
>>> I still think it's the option that best fits within the current canvas
>>> and WebGL semantics.
>>> 
>> 
>> Real GL doesn't give you lost context in this case AFAIK, It just fails to
>> make the new buffer. Why should WebGL be any different?
> 
> I don't know what happens in windowed mode OpenGL if you try to resize
> a window larger than the maximum supported viewport dimensions. I
> suspect that at least your app stops rendering. I doubt very much that
> OpenGL implements StretchBlt semantivs. WebGL wouldn't really be
> different in this regard.

I've experienced this one. If, on the window resize event, you set the framebuffer size to the size of the window and then set the viewport and redraw, when you resize the window to be too large, it will simply stop rendering. When I've done this I haven't looked at the errors returned, but I'm betting that it would be as expected. But I've never experienced any trouble with the context. You just resize below the threshhold and everything comes back. That seems like reasonable behavior here. 

Maybe we should synthesize a GL error or have some other error query mechanism so the author can tell whether or not the window was sized as requested? That way if authors don't want to do event handling, then can simply set width and height and then check for the error.

But generally I think this should be handled with a context error. It wouldn't be a "context lost", it would merely say that the request to size the window was not successful, so you need to get the size below the maximum. If this happens during a getContext(), the context should still be created and returned to the author. But no rendering will show up. I could go either way on whether or not subsequent rendering attempts return errors or are simply silently ignored. This makes the handling pretty simple:

	var gl = canvas.getContext("webgl");
	if (!gl)
		return "could not create a context";
	if (!gl.isDrawingBufferValid())
		setSize(gl.maxWidth, gl.maxHeight); // author supplies this to set the desired size given the passed max values

We should still have a context error event so the author can choose that style of processing.

We could make this a bit simpler if we specified the minimum supported frame buffer size. Then the author could:

	canvas.width = 256; // minimum supported width
	canvas.height = 256; // minimum supported height

	var gl = canvas.getContext("webgl");
	if (!gl)
		return "could not create a context";
	setSize(gl.maxWidth, gl.maxHeight); // author supplies this to set the desired size given the passed max values

This way the author can know that doing a getContext() will not fail because the size is too large. Not quite as clean, but doesn't require an extra function.

-----
~Chris
cmarrin@apple.com




-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: