[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 Nov 9, 2010, at 5:40 AM, email@example.com wrote:
> 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
> will need...or...
> * 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's a fine idea. But we still need to define the exact behavior. You say "keep the spec clean", but what does that mean? What do we do when a request for a too large drawing buffer is made? We have to answer that question to make a "WebGLUT" library, or any library to handle the case is a more clean way.
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: