> On Mon, Nov 8, 2010 at 8:17 PM, Mark Callow
>> 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
> not handling it now and so when their canvas gets stretched too large
> 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
> 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
> 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
> 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
>> canvas size, therefore special handling is needed for this error
>> 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 deal with.
>> 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.