[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Proposal: Generate INVALID_VALUE if value >= MAX_TEXTURE_IMAGE_UNITS on uniform1f(v) for samplers

It looks like I missed the line that stated that this was behaving differently. I thought this was merely trying to address a common dev error. It is, at least, abundantly clear we should add a test for this to the conformance suite.

I do *not* believe this is a bug with the spec per se, but rather a driver bug which should prevent the driver from passing conformance. Trying to use an invalid texture unit should fail should not switch out to a valid unit.

That said, leaving this behavior for historical reasons when there's no serious use-case for it is less than ideal. Having a tighter, easier-to-use spec, with less of the all-too-common silent failures, is, in my opinion, a great goal.

Let's do this change, but let's also be clear that this is not a strictly necessary change, but rather one made for clarity and ease of development.


----- Original Message -----
From: "Glenn Maynard" <glenn@zewt.org>
To: "Jeff Gilbert" <jgilbert@mozilla.com>
Cc: "Kenneth Russell" <kbr@google.com>, "public webgl" <public_webgl@khronos.org>, "Gregg Tavares (勤)" <gman@google.com>
Sent: Tuesday, May 1, 2012 5:17:58 PM
Subject: Re: [Public WebGL] Proposal: Generate INVALID_VALUE if value >= MAX_TEXTURE_IMAGE_UNITS on uniform1f(v) for samplers

On Tue, May 1, 2012 at 7:04 PM, Jeff Gilbert < jgilbert@mozilla.com > wrote: 

I don't think, though, that this is really necessary, since it's possible to emit JS warnings for this sort of stuff. I think these are plenty sufficient for detecting these issues for developers. 

I strongly disagree. If the same code causes different results in different browsers (and it's not an intentional variation, eg. different extensions), then it should be fixed to always do the same thing in all browsers. A web API not being interoperable is a bug. 

Also, if we do go down this path, we should consider checking for valid ranges for other types. 

That's only necessary if there are other cases which give different results in different implementations. If it's already consistent across all implementations (which it really should be--this one sounds like a GLES/GLSL spec bug if it's not a bug in one of the implementations), then it's not as important. 

Glenn Maynard 

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:
unsubscribe public_webgl