[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:50 PM, Steve Baker wrote:

> IMHO, there needs to be a distinction between opening an overly-large
> web context - and resizing one after creation.
> 
> In the former case, it would be nice if WebGL could do the best it can
> to meet your demands - just as it does if you demand (say) antialiassing
> and it can't do it.  Of course we must provide some means (such as
> querying the canvas.height/width) to find out that you didn't get what
> you wanted.   This allows simple applications to be as uncomplicated as
> possible and that's important for widespread adoption.

But the simple app would not be uncomplicated. If we set the size to something other than the requested canvas width and height we would have to do some sort of scaling, which would mess up the viewport, etc. And we can't set the width and height out from under the author. Even if we did, a simple app might not look at that and do the wrong thing anyway.

I think we need to fail to create the drawing buffer, but not fail to create the context, and let the author deal with it from there.

> 
> In the latter case - which is a more sophisticated operation, producing
> an error message and either refusing to do the resize or producing the
> largest allowed size would seem to be the simplest thing...again, with a
> way to query what you have left after all the fuss has died down.
> 
> I'd like to avoid loss-of-context stuff at all costs.

I don't think there is ever a need to have a context lost. In the case of using an FBO for the drawing buffer, the operation is definitely not destructive to the context. Even using a window manager, it's possible to resize the window without affecting the context, at least on all the platforms (WGL, CGL, GLX) I've used.

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