Working Group Info

I understand the working group has started. Is there any transparency on the process for non-members?

I’m also very interested in following the progress of the working group and would appreciate any links to public-facing resources/information.

I am also very interested on any informacion about WebGL as well as for the upcoming specs.

I am also very interested on any informacion about WebGL as well as for the upcoming specs.

same here… :slight_smile:

It’s really hard to guess for some OpenGL functions how they are ported to JavaScript.

I’ve found that a combination of the OpenGL ES book (Amazon.com) and this Mozilla page <http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/canvas/nsICanvasRenderingContextWebGL.idl&gt; has helped a lot when trying to figure out the API.

But yes, a formal spec would be really helpful! I’ve read elsewhere that a draft was planned for release in October, with a final version expected next year, but I don’t know if that’s (still) correct.

Cheers,

Giles

has helped a lot when trying to figure out the API.

yeah, but, for example, what about functions returning an CanvasArray, e.g. getFloatv? How to access these arrays?

Also: Is there a more efficient way to create CanvasArray’s as first creating an new JavaScript array, which is actually an hash table?

Re: getFloatv – fair point. I don’t think either that or getFloat is implemented yet in Minefield anyway.

Re: creating CanvasArrays – if there is, I’ve not see it! OTOH if you structure your code for efficiency – as you mentioned on the other thread :slight_smile: – and you only create them once when the page is loaded, then it’s not such a big deal, no? (Or are JS arrays really that inefficient?)

then it’s not such a big deal, no?

That does depend on the mesh size, and also not all data is static. :wink:
Think about an particle system. A fully GPU-based particle system might be possible, but without access to geometry shaders, transform feedback and TextureBufferObjects (TBO) this might be hard. There are more examples for dynamic data, e.g. text rendering.

Or are JS arrays really that inefficient?

I’m not sure how arrays are implemented in Firefox or Chrome, but associative arrays are allowed in JavaScript. I know that InternetExplorer does convert a index, say 42, first into an string “42” and computes then a hash value. The first few bits of the hash value are used as index in the internal array. However, IE 8 introduced a internal heuristic, which chooses between true array and hash map.

However, the biggest problem is to get the data into the array first. Parsing from a string might be really slow, but there is no other choice since binary formats are not possible in JavaScript. I assume the fastest way is currently to provide the mesh as JavaScript-Array and let the browser parse it using its native routines. The function eval() might be helpful here.

I think I will do some performance tests over the weekend.

not all data is static. :wink:

D’oh! Of course, excellent point.

I think I will do some performance tests over the weekend.

I’d love to see the results!

(Aside: associative arrays don’t have to be slow – Python uses them (it calls them dictionaries) for everything, including object method lookups, so they’ve optimised them to a quite amazing degree. Obviously it will never be as fast as a C array, but perhaps it can be fast enough that the effect of putting the new vertex positions into the array is negligible compared to the time it takes to calculate the new positions in the first place. Of course, more efficient is still better.)

I put this into an new thread. :slight_smile:

The minutes for yesterday’s Mozilla planning meeting (Mozilla Platform Meeting Minutes: 2009-12-01 « Meeting Notes) say that “[t]he WebGL standard goes to Khronos review this week. More public information will be forthcoming once the Khronos board approves it.”