[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] DOMException
On Thu, May 27, 2010 at 11:01 AM, Vladimir Vukicevic
> ----- "Kenneth Russell" <email@example.com> wrote:
> On Thu, May 27, 2010 at 9:25 AM, Alan Chaney <firstname.lastname@example.org> wrote:
>> This implies a guarantee that if a call to WebGL function fails because of
>> an underlying state issue (for example, if you try to use a program which
>> hasn't been linked) then any subsequent WebGL calls will always return
>> 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
> paragraph of http://www.khronos.org/opengles/sdk/docs/man/glGetError.xml
> 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.
Desktop OpenGL and OpenGL ES have the same semantics for glGetError.
Compare the second paragraphs in the following two manual pages.
It won't record two copies of the same error, but can record two
different errors which are then reported in an arbitrary order by
sequential calls to glGetError.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: