[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] DOMException
Vladimir Vukicevic wrote:
Its not a particularly important issue, but one irritating side effect
is that you must write error handling in such a way that as soon as you
check for it, if the status is non-zero you
----- "Kenneth Russell" <email@example.com> wrote:
On Thu, May 27, 2010 at 9:25 AM, Alan Chaney
> This implies a guarantee that if a call to WebGL function fails
> an underlying state issue (for example, if you try to use a
> hasn't been linked) then any subsequent WebGL calls will always
> without updating the error state? Is this a fair assumption?
No. There are conceptually multiple bits (one per type of error) in
the error state, and they are set independently. See the second
I don't think it's one per type of error, I think it's multiple errors
-- for example, maybe having one error per tile in a tile based
renderer or similar. We did however decide that this was incredibly
confusing, but we couldn't figure out how to get around it as it's
what the OpenGL ES spec states (desktop OpenGL has no such "multiple
flags" language). I'd be interested to know if any ES implementations
actually do keep multiple error flags around.
must remember the error status. For the sheer hell of it I just wrote a
little function which builds up a list of error strings assuming that
there may be multiple errors.
Its not obvious why ES and Desktop OGL are different. Sigh... Off-topic,
but as a developer who works with all 3 standards (OGL, ES2 and WebGL)
I'm very definitely in favor of a strategy of unifying them where possible.
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: