Earlier today we unveiled Find Your Way To Oz, a new Chrome Experiment inspired by the upcoming feature film Oz The Great and Powerful. Developed by UNIT9, this experiment brings together Disney’s unique storytelling tradition and the power of the web platform, allowing users to interact with the web in a completely new way.

The desktop version of “Find Your Way To Oz” uses many of the open web’s more advanced features:

• Immersive Graphics: The experiment uses WebGL for the main 3D environment, CSS3 features such as CSS Transitions for various visual embellishments, and GLSL shaders for the tornado’s ominous look and feel. 
• Rich Audio: As the user explores the experiment, the 3D sound dynamically adapts thanks to the Web Audio API. The same API powers the experiment’s music composing section. 
• Camera-based interactions: Through WebRTC’s getUserMedia API, users can become circus characters or record their own mini-movies. 

The experiment’s mobile web version also uses cutting-edge web technologies. These include graphics features such as accelerated 3D transforms and sprite sheets as well as mobile hardware features like camera, multi-touch, gyroscope and accelerometer. Together they create an experience that can normally only be found in native apps.

To learn more about how this experiment was built, read our technical case study and join us for a Google Developers Live event on February 11th at 11 a.m. GMT where we’ll be talking to the team behind the project. Alternatively, use Chrome’s developer tools to see how the experiment works on your own, perhaps finding in the process your own path to the yellow brick road.

A few weeks ago one of my developer friends was gushing about the capabilities of his favorite native platform. After every point I felt obliged to point out that the web platform either already had or was actively developing precisely the same capabilities—and then some. He was incredulous. "Prove it," he said.

So I pulled together a few of my favorite examples from the cutting edge of the web platform and recorded three screencasts to help my friend—and others—meet the web platform again for the first time.

The first video, Building on Foundations, goes over how the web platform has been fixing various historical shortcomings and building upon its core strengths, like complicated graphical effects, composability, and advanced text layout.

The next video, Learning from Other Platforms, reviews how the web platform offers new capabilities inspired by successes on other platforms with things like push notifications, payment APIs, and web intents.

Google’s aggressive strategy with Chrome has taken Chrome to a stage where it can claim a dominant browser-market share. Now, where does a company obsessed with speed and performance go from here? Google recently showed off how well Chrome can use the Native Client Technology. With this, Google Chrome will take browser wars to a new level.

The Native Client Technology in Google Chrome has been in news from the beginning of this year. While Mozilla had declared that they will not implement Native Client in their Firefox browser, Opera software had criticized Google for not following the web-standard (WebGL) and allowing game developers a free ride on their browser.

Google Native Client (NaCl in an allusion to sodium chloride or common salt) is a sandboxing technology for running a subset of Intel or ARM native code using software-based fault isolation. Currently in development, it is proposed for safely running native code from a web browser, allowing web-based applications to run at near-native speeds.

Adobe Air provides a Native Code API, and the recently launched Silverlight 5 also brings Native Code into the browser. Moreover, we all know about the notoriety of ActiveX in Internet Explorer. Although Native code has always been an area of interest across platform because of the promised robustness, it poses a risk at the same time.

The “Native Client Technology” project was started to create robust applications by allowing them to leverage native (system) processing speeds. It has been present in Google Chrome 14 dev version as a disabled feature. However, after this stunt by Google, “Native Client Technology” might be reduced to a game-enabling project, which kicks WebGL in the gut.

Visit the Native Client developer page here.

In March of last year we introduced ANGLE as the engine that would power Chrome's GPU rendering on Windows. At the time it was announced, ANGLE only supported a subset of the OpenGL ES 2.0 API. Thanks to continued work from TransGaming, in collaboration with Google engineers and other contributors, ANGLE has reached an important milestone: It now passes the rigorous OpenGL ES 2.0 test suite and ANGLE version 1.0 has been certified as a compliant GL ES 2.0 implementation. This is a major step forward for the project, and a major event for OpenGL ES support on Windows.

Mac and Linux already enjoy solid OpenGL support, but on Windows OpenGL drivers are not sufficiently widespread to be relied upon. Using ANGLE allows us to issue OpenGL ES commands in Chrome's graphics systems and not worry about the user's computer having OpenGL drivers -- ANGLE translates these commands into Direct3D 9 API calls.

ANGLE helps Chrome use a single, open graphics standard and remain portable across platforms. Because it's a standalone library, open-source project ANGLE can help other software projects in the same way. Firefox, for instance, is already using ANGLE to render WebGL content on Windows.

ANGLE is a necessary step in our continued efforts to push the web platform forward. Without ANGLE, it would be impossible to reliably run WebGL on many Windows computers, so we couldn't enable great applications like MapsGL. We hope WebGL developers and implementors will continue to join us in making ANGLE, and the open web platform, successful.

Editor's note: The Chromium WebGL team worked closely with the Maps team to help make MapsGL a reality. We invited a member of the Maps team to talk about their experience with MapsGL in the hope that it would help inform others who are interested in deploying a large scale WebGL app.

At this point it's almost hard to remember, but when Google Maps was first released in 2005, it was one of the first web applications to demonstrate what was possible with AJAX and the web platform. This project was a challenge technically but we’d like to think that it helped to fire the imaginations of web developers around the world.

Today, the Maps team is launching a beta of a brand new experience we call MapsGL. MapsGL is one of the first large scale applications to be built on top of WebGL. MapsGL makes use of 3D rendering and hardware graphics acceleration to provide an experience that is seamless, smooth, and runs directly in the browser.

Technically, MapsGL brings significant changes to how map and image tiles are rendered on the client and server. Rather than loading pre-rendered image tiles from servers, vector data for the map is sent to the browser and rendered on the fly using WebGL. This generally means that less data needs to be sent to the browser, but also that every aspect of the map needs to be rendered on the order of ~20ms per frame in order to achieve a reasonable frame rate. Imagery transitions in Maps are also enhanced by loading 3D metadata along with image tiles, allowing Maps to provide rich 3D transitions between different levels and angles of imagery.

While developing MapsGL, we found that WebGL draws from both native and web app backgrounds. For those used to working on web applications, WebGL adds a lot of functionality, but also increases the complexity of what you need to build and test. Even though WebGL is cross platform, performance varies dramatically across graphics hardware and operating systems - and what improves performance on one may hurt performance elsewhere - so testing across a wide array of setups is critical.

We also found that performance dependent Javascript and WebGL optimizations were needed in order for MapsGL to run properly on slower hardware. For example, there are a number of users with graphics cards that can't currently run WebGL content. In these cases, we don’t give the user the ability to opt-in and they can continue with the current Maps experience. Other graphics cards have somewhat poor performance for some key operations, which we measure with a small benchmark when the user first opts-in. In these cases, MapsGL falls back on a hybrid approach where we use pre-rendered raster tiles for the background of the map and only dynamically render labels on top of these.

We hope that MapsGL makes you excited to use WebGL in your own app. WebGL enables 3D graphics and immersive experiences in the browser that were formerly impossible. As WebGL becomes more robust and graphics card drivers improve, we can't wait to see what web developers will create with it. Check out the WebGL documentation and get started!

A few weeks ago, we became aware of a security issue with WebGL: shaders could be used to indirectly deduce the contents of textures uploaded to the GRU. As a result, the WebGL specification was updated to be more restrictive when it comes to using cross-domain images and videos as WebGL textures.

As a result, Chrome 13 (and Firefox 5) will no longer allow cross-domain media as a WebGL texture. The default behavior will be a DOM_SECURITY_ERR. However, applications may still utilize images and videos from another domain with the cooperation of the server hosting the media, otherwise known as CORS.

CORS support for MediaElements has also been fully implemented in WebKit by setting a new .crossOrigin attribute. This means that sophisticated applications that were using cross-origin textures before, can continue to do so, assuming the hosting image server grants the necessary cross-origin permission using CORS. If you want to enable CORS request on an image, all you have to do is add one line of code:

var img = document.createElement('img');
img.onload = function(e) { … };
img.crossOrigin = ''; // no credentials flag. Same as img.crossOrigin='anonymous'
img.src = 'http://other-domain.com/image.jpg';

Another nice property that we gain from this new setting is the ability to read cross-domain image data set on a 2D canvas. Normally, filling a canvas with a remote image (e.g. ctx.drawImage()) flips the origin-clean flag to false. Attempting to read back the pixels using ctx.toDataURL() or ctx.getImageData() throws a SECURITY_ERR. This is to prevent information leakage. However, when .crossOrigin is set (and the remote server supports CORS), the read is possible. For example:

var img = document.createElement('img');
img.onload = function(e) {
ctx.drawImage(img, 0, 0, canvas.width, canvas.height);
var url = canvas.toDataURL(); // Read succeeds, canvas won't be dirty.
};
img.crossOrigin = '';
img.src = 'http://other-domain.com/image.jpg';

Unfortunately, this new restriction in WebGL means that some existing content will break. We’ve already started working with external image and video hosting services like Flickr to evangelize the use of CORS on their images.

You can test this new behavior today using images from Picasa, which already sends a CORS header allowing cross-origin requests, and the Chrome dev channel.

The Khronos Group has finally put its stamp on the WebGL 1.0 spec, and that's good news for those of you running Firefox, Opera, Chrome, Safari, and any other up-to-date WebKit browsers. If you're an Internet Explorer user, however, you're still not invited to the party.

Microsoft, with IE9 only being available for Windows Vista and 7, is perfectly content with IE9's DirectX-based hardware acceleration. It will be interesting to see what happens with the mobile version of IE9, too -- if HTML5 and WebGL apps take off, Microsoft (and Nokia) will want to support them.

Mozilla's Jay Sullivan doesn't appear worried though, saying "Between Firefox and Chrome, people will build stuff." You can, of course, add WebGL support to Internet Explorer yourself -- by installing Google Chrome Frame, though admittedly that brings a whole lot more functionality than browser-based 3D.

If you've got a compatible browser and want to see what WebGL 1.0 can do, head on over to the Khronos Group demo site or check out Google's previous demo offerings!

Google has promoted three major Chrome features from the beta channel to the stable build. With the latest version of Chrome, all users can take advantage of WebGL, Chrome Instant and the Chrome Web Store.

WebGL brings hardware-accelerated 3D rendering to Chrome, making for some amazing graphics that could have gaming implications in the future. Right now, you can see it in action in several impressive demos. Chrome Instant will have a bigger immediate impact on users' day-to-day browsing. It loads your frequently-visited pages as you type into the address bar. No enter key required!

For folks who love extensions, themes and Web apps, the Chrome Web Store is the most important new feature. Now that the Web Store is open to all U.S. customers, Google has added a Web Store link and a couple of demo apps to the new tab page in the latest version of Chrome. They've also assured international users that the Web Store will be expanding to other countries soon.

As always, if you run Chrome, it will download the update automatically -- but you'll need to close and re-open it for the update to be applied.

Okay, so we're not quite at the point where you're going to be playing the next Crysis sequel in your browser, but still -- the arrival of WebGL in Chrome's beta channel is kind of a big deal. Apart from being able to play around with cool demos like the ones offered up by Google in its official announcement, WebGL is another important step in bringing more desktop-like functionality to the Web.

In addition to cloud-y 3D support, hardware acceleration support is due to arrive at some point -- presumably before Chrome 9 gets pushed to the stable channel. Whether or not that will happen remains to be seen, but we'll know soon enough thanks to the six-week release cycle.

Check your Chrome wrench icon for the update notification, or hit About Google Chrome to force a check.

Anyone else up for some WebGL Quake action?