Priorities for May

Choices, choices

The Canvas 3D API is getting pretty solid. The next step there would be writing a GLSL parser to validate shaders. I guess it'll run to around 2000 lines of code, so would take two months or so.

Regarding canvas performance issues (API call overhead, GC pauses, slow compositing), what I could do is write a draw list system, which'd be perhaps 500 lines of code (or 20 days) and help in getting rid of API call overhead. The other JS performance fixes would be rewriting the GC (which I would rather not do) and minimizing the JS->C call overhead (which I don't really know anything about, I hear quickstubs would help for the overhead), so I think I won't touch them for now.

Rewriting the compositing, while I believe I could do it, is a whole another can of worms. Basically, it's either going to be hellishly difficult or pretty easy. It would be pretty easy if the surfaces can be uploaded to OpenGL textures and drawn in the window clip area (plus upload timestamp to determine whether to re-upload texture.) But if that's too slow (i.e. if there's a zillion tiny surfaces changing all the time) or needs something special, then it's going to be hard.

The other related projects are writing a proof-of-concept OpenAL binding (guessing 5000 lines) and trying to port the GL canvas to some other browser (maybe a thousand lines?) Or maybe a GL canvas plugin (O3D-style)? The OpenAL experiment would teach some important lessons on the whole advanced audio thing.

On the tests side, a GLSL fuzzer would be nice to have, along with unit tests for the rest of the API. My devious plan to recruit other people to write them for me failed, so I guess I have to write them myself.

Priority lists

The entries in parentheses I'm not going to touch unless struck by divine inspiration.

Compatibility

1. GLSL parser - by July 1st
   1. Spike a quick ocamllex-ocamlyacc implementation to figure out the grammar, GLSL -> AST
   2. Write AST printer to output compatible GLSL
   3. Port over to some C library (first figure out which..)
2. GLSL subset spec - by July 1st
   1. Write in tandem with the parser
3. (GLSL compiler)

Tests

1. GLSL fuzzer - by August 1st
   1. Generate random ASTs and print them out
2. Unit tests for the whole API - by August 1st
   1. Start with one large test page, then split it as it progresses

Performance

1. (GC pauses)
2. (Slow compositing)
3. (General API overhead)
4. Draw list test - by June 1st
   1. Capture GL calls from JS, turn into an array of [function_id, args]
   2. Write a C++ DrawList-method that loops through the list and calls the wrapped GL functions
   3. Benchmark with a complex scene to see if it's worth the trouble

Other

1. OpenAL test, see if it makes sense - by September 1st
   1. Read through the API docs to figure out what it needs (and what it should provide)
   2. Write an OpenAL test app
   3. Strip out the GL-specific stuff from the Canvas 3D extension
   4. Change the API to bind OpenAL instead
   5. audioElement.getContext('moz-openal')?
2. (Canvas 3D plugin)

The whole non-parenthesized part of the above I estimate to take 4-5 months.. see you in September.

Updated 2009-05-06: more detailed plan