[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 Mon, Nov 8, 2010 at 8:17 PM, Mark Callow <firstname.lastname@example.org>
I, for one, am not prepared to sign off on something like this
based on what feels like a very sketchy description and no
explanation of how an application is supposed to handle this
situation. Furthermore I share Cedric's concern that most authors
will not handle it.
I'm not sure what you mean by "not handle it". As opposed to what? They are not handling it now and so when their canvas gets stretched too large their app crashes (throw an exception) They didn't handle it. The only recourse the user has is to resize the window smaller and refresh the webpage. Of course a user won't know to make the window smaller so they'll hit refresh, the app will fail to make a canvas at all the app will most likely not handle that case either and print "WebGL not supported"
Vs our suggestion. The app continues to function. Sure there might be some rendering issues but at least it hasn't crashed. Most likely the user can save their work/game whatever and then complain to the author later that their app needs work.
So right now we have 2 options on the table.
1) Leave it as is. App gets an exception or lost context or something along those lines. Most apps won't handle this and will effectively stop functioning until the page is refreshed and even then, only if the user resizes the page small enough
2) Make it as large as possible and stretch. Most apps won't handle this case either but at least they won't stop functioning. The debate here seems to be whether they should shoot for the same aspect ratio as originally requested or not. I'm on the "not" side.
Are you suggesting some 3rd alternative?
In native GL app's I let my resize event handler deal with
resizing things to whatever size the window system or user has
permitted. If I understand correctly, in the WebGL case the resize
events are based on the canvas size, therefore special handling is
needed for this error condition. How exactly does the application
handle the condition.
I am already having a hard time achieving what I'd like to do
regarding canvas size due to having to specify the size in pixels
- an insane idea given the wide variety of displays we have to
On 09/11/2010 10:14, Kenneth Russell wrote:
We need to resolve this issue quickly to get the spec to version 1.0.
I hope that you will agree with me that the behavior I've outlined
above is acceptable.