[Public WebGL] Size of GL_FLOAT

Kenneth Russell [email protected]
Wed Jan 13 11:19:57 PST 2010


On Wed, Jan 13, 2010 at 10:50 AM, Chris Marrin <[email protected]> wrote:

>
> On Jan 12, 2010, at 5:04 PM, Kenneth Russell wrote:
>
> > On Tue, Jan 12, 2010 at 4:57 PM, Vladimir Vukicevic <
> [email protected]> wrote:
> > On 1/12/2010 4:34 PM, Kenneth Russell wrote:
> >> On Tue, Jan 12, 2010 at 4:29 PM, Chris Marrin <[email protected]>
> wrote:
> >>
> >> On Jan 12, 2010, at 3:20 PM, Kenneth Russell wrote:
> >>
> >> > On Tue, Jan 12, 2010 at 3:12 PM, Chris Marrin <[email protected]>
> 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.
>

Please go ahead.

-Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100113/41f39a00/attachment.html>


More information about the public_webgl mailing list