[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Addition to WebGLContextLostEvent wrt extensions
On Thu, Apr 15, 2010 at 16:44, Gregg Tavares <email@example.com>
On Mon, Apr 12, 2010 at 11:08 AM, Cedric Vivier <firstname.lastname@example.org>
On Mon, Apr 12, 2010 at 10:03, Gregg Tavares <email@example.com>
These are great examples. I don't follow your conclusion though. In the first example getting GL_INVALID_OPERATION in no way informs you that you happened to have lost the context for a moment during initialization.
True, I'm not sure it is necessary but I agree the more specific the errors the better usually so we can just define that attempt to bind/use an invalidated WebGL object generates a GL_INVALID_NAME error instead right?
If we make up GL_INVALID_NAME is it only for names from lost contexts or is it also for names from other contexts? That seems like a confusing enum. If we go this route it should be GL_INVALID_OBJECT_FROM_LOST_CONTEXT
If I do not overlook something there is currently no defined behavior when an invalid object (e.g a buffer when a texture is expected, a deleted object, an object from another context,...) is passed to a method, generating a generic GL_INVALID_OPERATION would probably be enough, otherwise GL_INVALID_NAME or equivalent might make sense for all errors related to invalid name/object.
A specific error for objects that are not valid because their context have been lost provides little value imho, I do not see use cases where a developer would have to handle this specific kind of error differently considering we have events and isContextLost() if somehow required.
I think we all agree that Restored is not such a good idea if it cannot be defined/implemented with context restoration only just before the event is handled by user code.
If an app does not handle any context loss event the app should just stop working, automatic restoration whether or not the app actually even try to handle it would be confusing for both developers and users.
If it can be defined as described above, then the behavior would be equivalent to Resetable+reset().
No, it's not equivalent because in the Resetable+reset case the app gets to choose when the reset happens and therefore when WebGL functions will start working again. In the Restored case the app doesn't get to choose. It always happens in his event handler or not at all, whether or not the app in a good state to deal with it. (...)
As I said above, yes! we both agree _indeed_ that Restored is probably not such a good idea if we do not (or cannot) define it to behave exactly as Resettable+reset would.