Google has announced the availability of a plugin that implements 3D technology and makes it available over the web. You can read about the announcement in in the Google Code Blog and in an excellent article by Ryan Paul in Ars Technica.
Ryan points out that there are significant differences between what Google has built here and what we’ve built. I thought it might be worth it to expand on that a bit since it isn’t explained in depth in the Ars article.
Google’s 3D work is a plugin. So much like how Flash or Silverlight works you get a rectangle in the browser to draw into. They provide a high level scene graph API which uses the COLLADA format for loading objects underneath. It’s a very large chunk of code. If you take a look at the API and click around at the packages and classes you can see that there’s a lot there. Their use case is games and game-like things – virtual worlds. So it’s a great piece of work, but it’s also at a very high level.
Mozilla’s current proposal to Khronos is a very simple API that’s a wrapper around OpenGL ES 2.0. It’s currently available as an extension to Firefox 3.5 and is likely to be rolled into a version of Firefox after 3.5. The proposal is very focused on 3D. For example, we didn’t try to include video or audio because those are being covered by other web standards and we’re interested in making sure they are well integrated instead of trying to wrap those into a 3D spec. We’ve bound it to the canvas element so you can use it in much the same way you use the current canvas 2D context. Things like asset loading (via COLLADA or other systems) are things we haven’t dealt with because those can be handled entirely outside of the 3D api and layered on top of it. (Later in this post you’ll understand why this is important.) But the important thing is that it’s something that you can easily mix with the rest of the open web. Open Video and Audio, CSS, HTML, Canvas 2D, Canvas 3D, etc – you should be able to mix them all together and that’s our goal.
So these two 3D things from Mozilla and Google are pretty different. Not really competitive, either, because they have such different goals. The Google software is a very high level API 3D graphics API and what we’re proposing is more akin to the low level graphics API that those high-level systems are built on.
Given the title of the google blog post (“Towards an open web standard for 3D graphics”) it’s important to point out these differences since they affect how the standards process might look, and what the output might be. We’ve been through this a few times with different standards and it’s easy to point out what the key success factors are to build a successful standard. Here’s a quick iteration on those principals in my mind:
1. It’s important to keep the scope as small as possible.
The smaller the scope of the standard, the easier it is to understand the interaction of the various parts, what your goals are and what it takes to build an interoperable implementation. It’s also the easiest thing you can do to remain as future-proof as possible. It’s easier to add new APIs later if your scope is very very small.
2. Clear rules for interaction with the rest of content.
How does it work with the rest of the HTML spec? CSS? Video? Images? How can you copy content in and out? Can you use them as textures? These are just some of the questions that you have to raise as a way to describe how something like this might work with content. Once again, this is gated on #1 above – if the functionality is simple then the interactions can generally be pretty simple as well.
3. Allow the scope to change slowly over time.
Understanding that technology – especially on the web – does not exist in a vacuum outside of time. Standards do change over time and understanding how people use technology in the real world is the best possible way to understand how something should change and improve. Understanding that standards are an iterative process is important. Note that in #1 above – controlling scope – I mention that it’s important to keep things future-proofed via small and simple APIs. This is why – because you know that you will need to improve that API once you understand how people are using it in the field.
4. Allow most of the innovation to happen next to and on top of your API.
Last point – your standard should allow as much iteration and work to happen on top of your API as possible. This allows you to learn as much as possible about how people are using your software and gives them huge amounts of freedom to experiment and teach you about what you need to improve in the next iteration. If people are stretching your APIs and finding gaps in performance, you can add convenience APIs to make things faster – as long as they are simple APIs. We saw this in the real world with the JS libraries (dojo, jQuery) – we’ve been optimizing our engines and APIs over time to assist them as they have pushed our browsers to the limits. But we would not have known had we tried to implement everything that the libraries could have possibly done at the browser level.
OK, so those are the things that we think make for a successful standards process. I’ll point out one particular example of a dichotomy that I believe illustrates these rules so that people understand what I’m talking about: Canvas vs. SVG + SMIL.
Canvas is a very simple API (more info), much like what we’ve proposed to Khronos for 3D support. It’s well-scoped, well understood and integrates very well with other web technologies. And it’s been getting a huge amount of traction on the web. People are writing all kinds of really neat technology on top of it, including useful re-usable libraries for visualization. Have a look through Google’s own promotional site for Chrome – a huge number of them use canvas. It has traction. And we’ve gone through a couple of iterations – we’ve added support for text and a couple of other odds and ends once we understood what people were trying to do with it.
Now compare this to SVG and SMIL. Each of those specs are multi-hundred page documents with very large APIs and descriptions of how to translate their retained-mode graphics into something that’s usable on the web. (SVG 1.1 is a 719 page PDF. SVG 1.2 Tiny is 449 pages. The spec for SMIL is a 2.7MB HTML file.) We’ve seen some implementation of SVG and SMIL in browsers, but it’s been slow in coming and hasn’t seen full interoperability testing nor any real pick up on the web. The model for these specs was wrong, and I think it shows.
So I’ve spent some time talking about the context for standardization and what makes standards successful. How does this related to our stuff or Google’s stuff? Well, quite a bit actually. If we want something that browser vendors can easily implement, we need to understand that context and what we’re trying to standardize. Much of the work that Google did happened before browsers got as fast as they have, so there’s a good reason why they felt that they needed to implement so much of the code as native code and deliver it as a plugin. Their API is a good example of what a scenegraph API would look like on top of Canvas 3D. JS engines have gotten a lot faster since they started their plug-in and we think that it’s time that we start using them. Hence a low-level API that we can build on.
There’s a lot of great stuff going on with 3D on the web. We’ll be working with Google (and others!) via the Khronos group to try and standardize on a low-level API that browsers can support. It’s going to be a really fun year and I’m happy that we’re working to drive the web forward.
