[Public WebGL] gl.sizeInBytes

Chris Marrin [email protected]
Mon Jan 11 14:33:07 PST 2010


On Jan 11, 2010, at 2:13 PM, Philip Taylor wrote:

> On Mon, Jan 11, 2010 at 9:17 PM, Kenneth Russell <[email protected]> wrote:
>> On Mon, Jan 11, 2010 at 12:31 PM, Vladimir Vukicevic <[email protected]>
>> wrote:
>>> On 1/11/2010 11:48 AM, Kenneth Russell wrote:
>>> On Mon, Jan 11, 2010 at 10:37 AM, Chris Marrin <[email protected]> wrote:
>>>> 
>>>> So then maybe it would be better to replace these with constants
>>>> (ctx.FLOAT_SIZE, ctx.INT_SIZE, ctx.UNSIGNED_SHORT_SIZE), etc.?
>>> 
>>> I think we should leave sizeInBytes as a function rather than defining
>>> constants. On a hypothetical platform which defined GLfloat as a double, the
>>> WebGL implementation would be responsible for making WebGLFloatArray manage
>>> double-precision rather than single-precision floating point numbers.
> 
> Why does this matter for function vs constant? The WebGL spec could
> define ctx.FLOAT_SIZE etc to return implementation-dependent values,
> the same as sizeInBytes would return. (Maybe that conflicts with
> WebIDL's notion of "constant", but it could be defined as a property
> with a getter that returns the implementation-dependent value, so it's
> the same API syntax and implementation as a constant, as far as I'm
> aware). The only difference for function vs constant seems to be
> syntax ("gl.sizeInBytes(gl.FLOAT)" vs "gl.FLOAT_SIZE"), so it should
> be decided on ease-of-use rather than on implementation issues.

It matters only for consistency. Currently all "constant" values are defined as constants. The definition of a constant is that is has the same value on all platforms. If we have this one value that the spec says is the same value on all platforms, then for consistency, it should be a constant.

-----
~Chris
[email protected]




-----------------------------------------------------------
You are currently subscribe to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:




More information about the public_webgl mailing list