[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Addition of compressedTexImage2D entry points in WebGL 1.0.1
On Thu, Jan 26, 2012 at 2:54 PM, Kenneth Russell <firstname.lastname@example.org>
The queries also allow discovery of which compressed texture
On Thu, Jan 26, 2012 at 1:07 PM, Gregg Tavares (勤) <email@example.com
> On Thu, Jan 26, 2012 at 12:00 PM, Kenneth Russell <firstname.lastname@example.org
>> I think it makes sense to leave these enums as is, just in case it is
>> desired to allow one compressed texture extension to optionally
>> provide one or more formats.
> The goal of WebGL so far has been if you get an extension you have that
> feature. Leaving those 2 queries opens up extensions to break that idea. Why
> not just get rid of them and their by not allow extensions that are likely
> to break for devs who forget to check?
extensions have been enabled. This could be useful information for
debugging tools. I don't agree that the presence of the queries opens
up new failure modes. If you haven't enabled a particular compressed
texture extension then an INVALID_ENUM error is generated. This is the
same error that would happen if you enabled a compressed texture
extension that happened to not support a particular format, and then
attempted to use that format.
Getting rid of NUM_COMPRESSED_TEXTURE_FORMATS seems reasonable
contained in the length of the array returned from
getParameter(COMPRESSED_TEXTURE_FORMATS). Several other length queries
were removed from WebGL for this reason. Would you support just
removing this one and leaving the other?
Sounds reasonable to me.
>> On Thu, Jan 26, 2012 at 9:53 AM, Benoit Jacob <email@example.com
>> > ________________________________
>> > I'm curious is there any good reason to keep COMPRESSED_TEXTURE_FORMATS
>> > and
>> > NUM_COMPRESSED_TEXTURE_FORMATS are arguments to getParameter?
>> > They seem redundant. If you can only enable a format by checking for an
>> > extension then you can just check for the extensions.
>> > I would support removing them, then. Less code for us to write :-)
>> > Assuming, of course, that there is agreement that we want one extension
>> > per
>> > format. Which I'm fine with, I just didn't follow this discussion
>> > closely.
>> > Benoit