[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
<vladimir@mozilla.com> wrote:
>
> ----- "Kenneth Russell" <kbr@google.com> wrote:
>
> On Thu, May 27, 2010 at 9:25 AM, Alan Chaney <alan@mechnicality.com> 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.

http://www.khronos.org/opengles/sdk/docs/man/glGetError.xml
http://www.opengl.org/sdk/docs/man/xhtml/glGetError.xml

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.

-Ken

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: