I sat down, tried to concentrate, and came up with a list of things I imagine the API ought to be able to do. These are pretty lame (still too hard for average folk to make use of), but it’s hard for a programmer to come up with ways to create things both useful and beautiful. Especially in 3D. Plus we need a platform before we get to the aplication layer, and right now we don’t have it, all we have is a sometimes-working OpenGL context. So assuming our goal is not Doom without sound in the web browser, it’s a decent beginning. For those who actually read our blog – you should know these are just my ideas and have not been reviewed by anyone else yet. api-use-cases-v02.pdf P.S. I’m not completely sure ‘use cases’ is the right thing to call the stuff in that document, they both are and are not use cases. It turned out to be more of a design document.. I don’t know. I’ve done what I can for now with the library’s performance. For the same 4 cubes (as long as they’re not spinning) I now get 40FPS with ~5% CPU usage. That’s quite an improvement from the 20FPS/95%CPU it was before. The trick was to make sure I don’t recalculate the position/orientation of the objects if they’re obviously not going to move (velocity is 0), plus don’t redraw if no updates were made to the camera or the objects. For now any further work on performance is a waste of time in my opinion. We need to get some applications that at least resembe realistic use cases, and fix performance problems when they really are problems. The updates I made were to FreeCamera and Cube only. I guess now we actually need to get some inheritance in here (JavaScript inheritance, yuck). Maybe I’ll work on that next. Here are the results of my performance analysis, with FPS the number of times Scene::render() runs:
  • With no rendering/updating whatsoever, setInterval(render, 1): 96FPS
  • With only updateObjects(): 40FPS
  • With only renderObjects(): 28FPS
  • With only swapBuffer(): 40FPS
  • With only clear() and clearColor(): 40FPS
  • With everything but renderObjects(): 38FPS
  • With everything: 20FPS
I think it’s safe to assume that 96FPS (plus a bit to account for my logging code) is a JavaScript limitation for calling a function, so we shouldn’t aim for anything higher than that. Otherwise it doesn’t look like there is much of a bottleneck, only renderObjects takes 25% more time than the rest. For reference: this is using ~95% of my CPU; playing a flash video from youtube.com uses ~30% in both Safari and Firefox. For now I’m going to dig in a little deeper, to see if I can figure out where the CPU time is being used. But I suspect I’ll just find it’s all spent in calling functions and the work the Canvas3D extension does. Ultimately this may not be a huge issue (depending on how much an effect adding polygons/textures will have), since we won’t be redrawing unless something’s changed. I’ll also do some experiments with that today. I spent the whole day today adding error reporting to Mark’s code. I expected complications because I have no idea how the code works, but I didn’t expect there to be no mechanism for error reporting at all. Can’t write from a webpage to the error console, or the terminal. Understandable, but annoying. Basically what you need to know is that we can now use logError(str), logWarning(str), and logInfo(str). The result of either call will be a colour-coded, timestamped, absolutely-positioned string at the bottom of the webpage. I was hoping to use the new logging code to help me find the performance bottleneck(s), but there isn’t much time left today, so maybe tomorrow. p.s. this logging code, if developed to maturity, would be an invaluable tool for serious webmasters, but sadly that’s out of scope for this project. The Canvas 3d Library site (http://www.c3dl.org) is now officially up and running. The site was built by the PHUG group and they did a fantastic job of making it look good. I’m really excited about the possibilities for our project. Currently we are not able to provide actual samples of Canvas 3D right on our site as it is not supported by today’s browsers. One day when it is supported, I think it would be really neat to just have samples built using our libraries right on our page. For now we’ll have to settle for quicktime captures (coming shortly)