Comments for An Now For Something Entire....Oooh! Shiny!
The issue with direct surfaces is that you need highly performant execution of the code that's managing your custom scene graph, hit-testing, etc. Even V8 is going to run really hot doing this, though things like http://code.google.com/p/nativeclient/ should help.
Alex is probably sick of hearing me rant about "expose more hardware to web developers" by now...
If the browser is an OS (and I suggest not-so-humbly that it is), it's got to be productive and safe to succeed it's predecessors in a meaningful way. Java exposed lots of hardware in craptastic ways which is why lots of discussions about doing interesting things on the web end at plugins but always give you this weird "it's going to hurt" kind of taste in your mouth. I think O3D is doing better there by putting productivity first and control second. There's a strong case for both, but the productivity horse is clearly pulling the cart.
Regards
Gavin, Yes, that's true, but often you end up still need to manage the scene graph anyway, or some lower res pre-baked version, even if the render loop is handled for you. "Picking" is a low hanging fruit for many games. For example, if you're doing path-finding algorithms, you need to walk a scene graph yourself. Or maybe you're doing objectobject collision detection for rudimentary physics.
I'm sure one of the first thing someone's gonna do is port ODE to JS.
I agree managing all the pipeline state in JS could be slow, then again, with DIsplay Lists it might be manageable.
Anyway, with respect to Java, I think Java2D/JAI exposed things in a rather nice way, but Java3D's scenegraph left alot to be desired (except for the very nice geometry compression) Java had the problem of trying to support multiple platforms which had poor interoperability (Linux had really crappy font and 2D capability when Java2 was first released, and DirectX still sucked then). Nowadays, all 3 platforms (Win/OSX/Linux) have very nice 2D and 3D mature APIs, so it's alot easier to expose low level APIs than it used to be. Anyone trying to do multiplatform libraries back in those days had their work cut out for them. Even interoperability on Windows between cards was poor.
As a matter of fact there are several areas that can be automated in the interactive computer graphics, e.g., a picture regeneration, an animation, an event processing, and so on, and strictly speaking these needs could be better served by different scene graphs with different organization.
O3D seems to solve this partially (from my quick reading), by giving you declarative control tree traversal, as well as the ability to specify render targets
Still, I would like to see both OpenGL and OpenCL exposed directly, even if O3D is built on top, just like there is a place for both SVG and Canvas.