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

Re: [Public WebGL] A different approach to interleaved typed arrays

On Jun 4, 2010, at 12:47 PM, Vladimir Vukicevic wrote:

> ...
> I'm in general agreement with Ken here -- I just don't see the aliasing/endianness issues as a significant showstopper problem.  I'm interested in the TC-39 struct proposal purely from a developer convenience point of view, because being able to access interleaved array data in a more natural form (like foo[i].vertex.x, foo[i].normal.y, foo[i].color.r, etc.) would be nice, though only if the implementations can get that indexing to be close to typed array speed.  Having it fix the endianness exposure issues is, to me, only a nice side benefit.
> Current typed array indexing is:
>  base_ptr + index<<elemsize_shift
> The struct proposal could be, with enough parser work:
>  (base_ptr + structsize*index) + member_offset
> (Though base_ptr+offset will be constant for each element, so maybe there's something useful that can be done there.)
> The interleaved proposal above would be, I believe:
>  stride = elementsPerGroup*elemsize + bytesToNextGroup
>  (ptr + stride*(index/elementsPerGroup)) + (index % elementsPerGroup)

Your indexing scheme does look better, but think about where that 'index' value is coming from. In the current scheme filling an interleaved array requires index arithmetic in JavaScript. You essentially have to do this:

	var index = 0;
	for (var i = 0; i < values.length; i += 3) {	
		floats.set(index++, values[i]);
		floats.set(index++, values[i+1]);
		floats.set(index++, values[i+2]);

In my scheme, all that is done in native code. From a standpoint of optimizing JavaScript to more efficiently access the structure of the views I don't think the difference is significant. The more extensive math you show for accessing my structure can be optimized out because elementsPerGroup, elemsize and bytesToNextGroup are all constant for a given view.

So I don't think the "less efficient" argument holds. 

The reason I get concerned about the endianness issue is because I think we've done a great job of hiding all the gritty, crash-prone issues of OpenGL ES. And while it wouldn't cause browser crashes, the ease with which an author can expose the endianness of the machine is troubling. If we can button that up (and I think we can) then we will have a better API


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