<meta http-equiv="content-type" content="text/html; charset=utf-8"><div>I don't think we should disallow passing Float64Array to bufferData or bufferSubData</div><div><br></div>Let me put this another way with an example<div>
<br></div><div>// Get some data (this could be replaced by XHRing the data)</div><div>// The data is in the format float[3] position, uint8[4] color, double[2] normalUsedInJS</div><div><br></div><div>var untypedBuffer = new ArrayBuffer(96);</div>
<div>var asFloats = new Float32Array(untypedBuffer);</div><div>var asUint8s = new Uint8Array(untypedBuffer);</div><div>var asDoubles = new Float64Array(untypedBuffer);</div><div><br></div><div>// Triangle positions</div><div>
asFloats[0] = 0.0; asFloats[1] = 0.5; asFloats[2] = 0;</div><div>asFloats[12] = 0.5; asFloats[13] = -0.5; asFloats[14] = 0;</div><div>asFloats[24] = 0.5; asFloats[25] = -0.05; asFloats[26] = 0;</div><div><br></div><div>// Colors</div>
<div>asUint8s[12] = 255; asUnit8s[13] = 0; asUnit8s[14] = 0; asUnit8s[15] = 255;</div><div>asUint8s[44] = 255; asUnit8s[45] = 0; asUnit8s[46] = 0; asUnit8s[47] = 255;</div><div>asUint8s[76] = 255; asUnit8s[77] = 0; asUnit8s[78] = 0; asUnit8s[79] = 255;</div>
<div><br></div><div>// other data, to be used by JavaScript</div><div>asDoubles[3] = Math.sin(0); asDoubles[4] = Math.cos(0);</div><div><div>asDoubles[7] = Math.sin(Math.PI * 2 / 3); asDoubles[8] = Math.cos(Math.PI * 2 / 3);</div>
</div><div><div><div>asDoubles[11] = Math.sin(-Math.PI * 2 / 3); asDoubles[12] = Math.cos(-Math.PI * 2 / 3);</div></div></div><div><br></div><div>Would might not do this directly in JS but I would XHR that data it so I had 1 XHR for all my data instead of 2 XHRs and I'd be happy to upload it all to the card to avoid having the split it at runtime. </div>
<div><br></div><div>Given that, All of these should work and accomplish the exact same thing</div><div><br></div><div>gl.bufferData(gl.ARRAY_BUFFER, untypedBuffer, ..);  // uploads all 96 bytes of mixed data</div><div><div>
gl.bufferData(gl.ARRAY_BUFFER, asFloats, ..);  // uploads all 96 bytes of mixed data</div></div><div><div><div>gl.bufferData(gl.ARRAY_BUFFER, asUint8, ..);  // uploads all 96 bytes of mixed data</div></div></div><div><div>
<div>gl.bufferData(gl.ARRAY_BUFFER, asDoubles, ..);  // uploads all 96 bytes of mixed data</div></div></div><div><br></div><div>Disallowing the last line doesn't give us one iota of type safety so why specifically disallow it?  All 4 statements are doing exactly the same thing. Uploading mixed data and lying about the type of data in the buffer. Well, I suppose the first one isn't lying since it's not claiming any type but the other 3 are.</div>
<div><br></div><div>If we're serious about type safety we'd track the type used to put data in the buffer and disallow other uses on vertexAttribPointer. We aren't going to do that.The API allows the user to upload any crap they want. Adding one exception out of 9 types of ArrayBufferViews, the other 8 of which do not actually guarantee what's in them is silly.</div>
<div><br></div><br><div class="gmail_quote">On Mon, May 23, 2011 at 11:46 AM, Kenneth Russell <span dir="ltr"><<a href="mailto:kbr@google.com">kbr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Mon, May 23, 2011 at 11:23 AM, Chris Marrin <<a href="mailto:cmarrin@apple.com">cmarrin@apple.com</a>> wrote:<br>
><br>
> On May 20, 2011, at 6:50 PM, Kenneth Russell wrote:<br>
><br>
>><br>
>> In the bufferData and bufferSubData variants taking ArrayBufferView,<br>
>> we failed to specify what happens if a Float64Array is passed.<br>
>> <a href="http://www.khronos.org/registry/webgl/specs/latest/#5.12" target="_blank">http://www.khronos.org/registry/webgl/specs/latest/#5.12</a> mentions that<br>
>> Float64Array can not be used with WebGL, but does not specify what<br>
>> happens if an attempt is made.<br>
>><br>
>> The other entry points which take ArrayBufferView (readPixels,<br>
>> texImage2D, texSubImage2D) also take a type enum, and generate<br>
>> INVALID_OPERATION if that type enum and the type of the<br>
>> ArrayBufferView do not match. Therefore, these entry points will<br>
>> already generate INVALID_OPERATION in this case.<br>
>><br>
>> Options seem to be:<br>
>><br>
>> 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed.<br>
>> 2. Change the IDL in the WebGL spec to explicitly enumerate all of<br>
>> the ArrayBufferView subclasses accepted for bufferData, bufferSubData,<br>
>> readPixels, texImage2D, and texSubImage2D.<br>
>><br>
>> Firefox 4 currently has a bug where it silently accepts Float64Arrays<br>
>> for bufferData, so some change is definitely needed.<br>
>><br>
>> I would probably recommend (2) despite the slight explosion in the IDL<br>
>> because it's most compatible with the intent of the spec. This would<br>
>> mean that an exception would be raised per the Web IDL spec.<br>
><br>
> Enumerating types wouldn't prevent errors in all cases. If you pass an ArrayBuffer that happens to contain Float64 data, either in its entirety or interleaved with other types of data, there would be no way to detect the error. There's also no way to detect the error when you pass a Float32 array and you should have passed in an Int32 array.<br>

<br>
</div>Yes, both of these are true.<br>
<div class="im"><br>
> There are cases where it might be perfectly valid to pass a Float64Array to bufferData. The author might be storing 64 bit floats interleaved with other data types.  With proper offsets the 64 bit floats would be ignored by the WebGL drawing commands. The author might be passing the data as a Float64Array because the first data value happens to be a 64 bit float and passing it makes the offsets come out right. I'm not saying that's the best way to manage your WebGL buffers, but it is a reasonable thing to do.<br>

<br>
</div>This sounds like a pretty esoteric use case. The 64-bit floating point<br>
data would only be legally accessible on the CPU due to OpenGL ES 2.0<br>
API restrictions, but the rest of the data would be being uploaded to<br>
the GPU. Presumably once the other data is uploaded to the GPU, the<br>
CPU side copy should be discarded, but that wouldn't be possible<br>
because of the data interleaving. This would result in two times the<br>
space being consumed, part on the GPU and part on the CPU, than<br>
otherwise should be.<br>
<div class="im"><br>
> I don't think we can or should put any restrictions the types passed to bufferData.<br>
<br>
</div>I think that at least some error check should be done here since it's<br>
very unlikely that a developer would intentionally try to upload a<br>
Float64Array. Generating an INVALID_VALUE OpenGL error would be fine<br>
but I think that at least some check is needed.<br>
<br>
-Ken<br>
<div><div></div><div class="h5"><br>
> -----<br>
> ~Chris<br>
> <a href="mailto:cmarrin@apple.com">cmarrin@apple.com</a><br>
><br>
><br>
><br>
><br>
><br>
<br>
-----------------------------------------------------------<br>
You are currently subscribed to <a href="mailto:public_webgl@khronos.org">public_webgl@khronos.org</a>.<br>
To unsubscribe, send an email to <a href="mailto:majordomo@khronos.org">majordomo@khronos.org</a> with<br>
the following command in the body of your email:<br>
unsubscribe public_webgl<br>
-----------------------------------------------------------<br>
<br>
</div></div></blockquote></div><br>