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.

Posted by Max Heinritz, Product Magician (Manager)

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.



The last video, On the Cutting Edge, demonstrates some of the new tricks the web platform is learning, like webcam access, powerful audio APIs, and complicated 3D graphics.



If you're interested in learning more about the technology behind any of the demos, check out the Meet the Web Platform companion guide.

I hope these videos capture your imagination and begin to show what is possible on the web platform. The web platform is evolving at an enormous pace, and I just can't wait to see where it goes next!

Posted by Alex Komoroske, Product Manager

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.

Posted by Vangelis Kokkevis, Software Engineer

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!

Posted by Jennifer Maurer, Software Engineer on the MapsGL team

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 GPU. 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. { … };
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. {
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.

Posted by Eric Bidelman, Developer Advocate

Posted by Henry Bridge, Product Manager

Posted by Ken Russell, Software Engineer