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

Re: [Public WebGL] Size of GL_FLOAT



On Jan 12, 2010, at 5:04 PM, Kenneth Russell wrote:

> On Tue, Jan 12, 2010 at 4:57 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
> On 1/12/2010 4:34 PM, Kenneth Russell wrote:
>> On Tue, Jan 12, 2010 at 4:29 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> 
>> On Jan 12, 2010, at 3:20 PM, Kenneth Russell wrote:
>> 
>> > On Tue, Jan 12, 2010 at 3:12 PM, Chris Marrin <cmarrin@apple.com> wrote:
>> >
>> > On Jan 12, 2010, at 3:08 PM, Kenneth Russell wrote:
>> >
>> > > ...We already specify the size of each type in the WebGLArray. That constrains what the vertex arrays can contain, which constrains the underlying OpenGL (or other) implementation. If a WebGLFloatArray contains 32 bit floats in every implementation and the VBO is sent in and defined as a buffer of FLOAT type, then WebGL constrains the type of FLOAT to be 32 bits.
>> > >
>> > > This is one way of looking at it: that the WebGL spec implies constraints on the OpenGL implementation underneath, for example that it supports 32-bit floats as input data. Another way of looking at it is that WebGL conforms to the typedefs of the OpenGL implementation on the platform.
>> > >
>> > > So wouldn't it be best to remove sizeInBytes() and replace it with constants for each supported WebGLArray type? This might be best done with a constant in each WebGLArray subtype (WebGLFloatArray.SIZE, WebGLUnsignedByteArray.SIZE, etc.).
>> > >
>> > > Realistically I think that every OpenGL implementation out there will support the primitive data types currently in the WebGL spec, so it's OK with me if we make this change. I would suggest a name like WebGLFloatArray.ELEMENT_SIZE to be more clear about the meaning.
>> >
>> > ELEMENT_SIZE makes me thing of elements in an array, not bytes. Maybe we should just go with SIZE_IN_BYTES (as wordy as that is), or BYTE_SIZE? :-)
>> >
>> > I don't like SIZE_IN_BYTES or BYTE_SIZE because we already have a method called byteLength(). We should have an indication that we're talking about the size of one element in the array.
>> 
>> I misspoke; it's an attribute, not a method.
>>  
>> Speaking of which, I'd feel better if this were lengthInBytes or something. Right now it sounds like its describing the length of a byte!
>> 
>> There's currently naming consistency between the byteOffset and byteLength attributes on WebGLArray, and the byteLength attribute on WebGLArrayBuffer. Personally I like these better than offsetInBytes and lengthInBytes. Other opinions?
>>  
>> >
>> > What about ELEMENT_SIZE_IN_BYTES? ELEMENT_BYTE_SIZE?
>> 
>> BYTES_PER_ELEMENT?
>> 
>> This sounds good.
> 
> BYTES_PER_ELEMENT sounds good to me as well.  On each of the typed array types, correct?  (WebGLFloatArray.BYTES_PER_ELEMENT == 4?)
> 
> Yes, on each of the array types.

So should we make this change? I can do it unless Vlad or Ken wants to take it on.

-----
~Chris
cmarrin@apple.com




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