[Public WebGL] Oversight in bufferData and bufferSubData specification

Gregg Tavares (wrk) [email protected]
Sat May 21 11:14:52 PDT 2011


On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell <[email protected]> wrote:

> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) <[email protected]>
> wrote:
> > Why does it matter?
> > in real GL, bufferData and bufferSubData just take void* and a length so
> it
> > seems like any ArrayBufferView should be valid.
> > I can do this now
> > gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView);   // upload bytes,
> > gl.vertexAttribPointer(0, 3, gl.FLOAT, ...)   // use as floats
> > or visa versa
> > gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView);   // upload
> floats,
> > gl.vertexAttribPointer(0, 3, gl.BYTE, ...)   // use as bytes
> > so why does it matter that I can upload a Float64Array? What I upload and
> > how I used it are not related in WebGL
>
> Misinterpretation or reinterpretation of uploaded data is irrelevant.
> OpenGL ES 2.0 does not support double-precision floating point values
> at all and neither does WebGL. Uploading a Float64Array into a buffer
> object will only result in garbage values that can not be properly
> referenced as vertex attributes.
>
> From the standpoint of strongly typing the IDL, only the
> ArrayBufferView subclasses that can legally be used in the API should
> be accepted. If a future version of WebGL begins to accept
> double-precision floating-point values, then the IDL could either be
> changed to add overloads taking Float64Array, or could be changed back
> to what it is now, taking the superclass ArrayBufferView.
>

I don't agree. bufferData doesn't have a type like texImage2D so you can't
validate that they are passing in valid data. It's not worth complicating
the IDL or even checking for this case IMO.

I can download float32 data and do this

var bogusView = new Float64Array(someFloat32Array);
gl.bufferData(gl.ARRAY_BUFFER, bogusView);  // Shouldn't matter. I'm still
uploading Float32 data.

Why does it matter? Changing this will not add even 1 bit of safety. In fact
as it is now you can upload an ArrayBuffer, untyped. There is zero need to
check for Float64Array since the API can't validate any of the other cases.
There is no reason to complicate it now for one out of million cases.






>
> -Ken
>
> > On Fri, May 20, 2011 at 6:50 PM, Kenneth Russell <[email protected]> wrote:
> >>
> >> In the bufferData and bufferSubData variants taking ArrayBufferView,
> >> we failed to specify what happens if a Float64Array is passed.
> >> http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that
> >> Float64Array can not be used with WebGL, but does not specify what
> >> happens if an attempt is made.
> >>
> >> The other entry points which take ArrayBufferView (readPixels,
> >> texImage2D, texSubImage2D) also take a type enum, and generate
> >> INVALID_OPERATION if that type enum and the type of the
> >> ArrayBufferView do not match. Therefore, these entry points will
> >> already generate INVALID_OPERATION in this case.
> >>
> >> Options seem to be:
> >>
> >>  1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed.
> >>  2. Change the IDL in the WebGL spec to explicitly enumerate all of
> >> the ArrayBufferView subclasses accepted for bufferData, bufferSubData,
> >> readPixels, texImage2D, and texSubImage2D.
> >>
> >> Firefox 4 currently has a bug where it silently accepts Float64Arrays
> >> for bufferData, so some change is definitely needed.
> >>
> >> I would probably recommend (2) despite the slight explosion in the IDL
> >> because it's most compatible with the intent of the spec. This would
> >> mean that an exception would be raised per the Web IDL spec.
> >>
> >> -Ken
> >> -----------------------------------------------------------
> >> You are currently subscribed to [email protected]
> >> To unsubscribe, send an email to [email protected] with
> >> the following command in the body of your email:
> >> unsubscribe public_webgl
> >> -----------------------------------------------------------
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110521/bffc1b52/attachment.html>


More information about the public_webgl mailing list