[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?
We seem to be arguing between:
* Mandatory application-side complexity that's unlikely to be handled
correctly by 90% of web sites...or...
* Removing application-side flexibility that more advanced applications
* Adding uncomfortable amounts of complexity into the WebGL specification
very late in the game.
None of those things are particularly attractive.
So maybe the answer here is to keep the spec clean and hide the resulting
application-side complexity issues by providing something like the GLUT
library for OpenGL.
WebGLUT could be small and light-weight and provide inflexible behavior
that would be simple to use and understand - and guaranteed "correct".
That would achieve the goal of allowing people to use WebGLUT get simple
programs up and running that behave reliably and predictably...while
letting people with more serious applications have access to
harder-to-use-but-more-flexible interfaces at the WebGL level.
I know that there are already several 3rd party libraries - but they
appear to wrap more than is needed and provide higher level interfaces
across the board that most certainly isn't to everyone's tastes. They
also don't have the "Khronos seal of approval" thing going for them. If
we expect people to use WebGL much like they have historically used OpenGL
- then providing a WebGLUT library to handle the ikky stuff makes some
kind of sense.
If WebGLUT were to be featured in the WebGL programmers' guide (the "Red
Book"), then people would be able to get to grips with the more
interesting bits of WebGL quickly without having to fight to do the very
first step...opening a rendering context. Buried someplace at the back of
the book, we could explain the more horrific issues of opening a valid
rendering context without using WebGLUT - but if most readers never get
that far, then that's OK.
> 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.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: