Changes in Firefox Nightly 2009/11/02

An hour ago I updated to the latest nightly build of firefox, see build identifier below.

As far as I got it up to now they changed the parameters stride and offset in vertexAttribPointer. It counts now in bytes, no longer in floats. Also it’s possible that the required size for an VBO is now calculated absolutely wrong, because still counting in floats. However, I have to go more into this…

Does anyone knows where to find an changelog?

Build Identifier:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091102 Minefield/3.7a1pre

I don’t find anything about this here:
http://hg.mozilla.org/mozilla-central/p … +month+ago

Ouch, nasty! I’ll hold off on upgrading on my main development machine, then. Measuring these things in bytes sounds wrong to me, floats seem to make much more sense.

No, bytes is correct. That allows to create interleaved arrays with different data types. E.g. Position as RGB32F and Color as RGB8. And WebKit seems also to use bytes…

E.g. Position as RGB32F and Color as RGB8.

However, I think it’s not possible to create an CanvasArray which contains different types like that.

Hmm, I see what you mean. From the viewpoint of compatibility with OpenGL ES I guess the parameters should be in terms of bytes. This could potentially also allow interleaved arrays, as you say.

However, from a pure JavaScript viewpoint, and because it looks like every CanvasArray must have only one type in it right now, it would be nice if the stride and the offset were in terms of “the things I put into the CanvasArray” – so, in terms of floats for CanvasFloatArray or bytes for CanvasByteArrays etc. This means you don’t need to know how many bytes long a float is, and so on.

Perhaps this is one of the points still under discussion among the group putting together the spec; it’s a pity none of them are posting here… but if they’ve changed the parameters in Minefield (even if they’ve introduced bugs by so doing) then presumably the tide is turning in the direction of using bytes – which would seem to imply that they’ll have to add some way of creating hetrogenous arrays, as otherwise the change will just be confusing and unhelpful. I’ll be interesting to see what kind of API they come up with for that!

I have update the bug description and added to samples:
https://bugzilla.mozilla.org/show_bug.cgi?id=521667

It is possible to hold different types in the same buffer:
http://blog.vlad1.com/2009/11/06/canvas … nvasarray/

It is possible to hold different types in the same buffer:
http://blog.vlad1.com/2009/11/06/canvas … nvasarray/

wtf? did you make it work? when i make:

var f2 = new CanvasFloatArray([12.3, 23.4, 34.5]);

f2[0] stays undefined
eather when i make my buffer like:

var buf = new CanvasArrayBuffer(192); // same value from above
var points = new CanvasFloatArray(buf);
var colors = new CanvasUnsignedByteArray(buf);
points[0] = 12.3;
points[1] = 23.4;
points[2] = 34.5;
colors[12] = 0xff;
colors[13] = 0xaa;
colors[14] = 0x00;
colors[15] = 0x00;

and then past points and color to gpu it’s still empty.

give me some working example please :wink:

sorry for my english, i’m drunk :stuck_out_tongue:

wtf? did you make it work?

No, it’s not working for me either. Vladimir is one of the Mozilla developers, so I assume this is not yet in the nightly-trunk.

Yup, not working for me either in Firefox. However,


var f2 = new CanvasFloatArray([12.3, 23.4, 34.5]);
alert(f2[2]);

…works in Chrome.

It’s probably worth adding – I’ve got loads of code that does things like this:

    var vertices = [
         0.0,  1.0,  0.0,
        -1.0, -1.0,  0.0,
         1.0, -1.0,  0.0
    ];
    gl.bufferData(gl.ARRAY_BUFFER, new CanvasFloatArray(vertices), gl.STATIC_DRAW);

…and I’m sure everyone else has similar stuff. So that presumably means that it’s just the reading of the CanvasFloatArray that’s broken, not the actual creation and setting of the values.

Only the following works in Firefox so far:

var cfa = new CanvasFloatArray(...);
alert("len=" + cfa.length);

Yup. On the other hand, the data must be getting stored somewhere, even if the [] operator can’t retrieve it – otherwise the call to gl.bufferData wouldn’t get passed anything in the example code I gave…