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.

In September 2010 we announced the WebP image format with lossy compression. WebP was proposed as an alternative to JPEG, with 25–34% better compression compared to JPEG images at equivalent SSIM index. We received lots of feedback, and have been busy improving the format. Last month we announced WebP support for animation, ICC profile, XMP metadata and tiling. Today, we introduce a new mode in WebP to compress images losslessly, and support for transparency – also known as alpha channel – in both the lossless and lossy modes.

With these new modes, you can now use WebP to better compress all types of images on the web. Photographic images typically encoded as JPEG can be encoded in WebP lossy mode to achieve smaller file size. Icons and graphics can be encoded better in WebP lossless mode than in PNG. WebP lossy with alpha can be used to create transparent images that have minimal visual degradation, yet are much smaller in file size. Animations compressed as GIFs can use animation support in WebP.

New lossless mode

Our main focus for lossless mode has been in compression density and simplicity in decoding. On average, we get a 45% reduction in size when starting with PNGs found on the web, and a 28% reduction in size compared to PNGs that are re-compressed with pngcrush and pngout. Smaller images on the page mean faster page loads.

New transparency mode

Today, webmasters who need transparency must encode images losslessly in PNG, leading to a significant size bloat. WebP alpha encodes images with low bits-per-pixel and provides an effective way to reduce the size of such images. Lossless compression of the alpha channel adds just 22% bytes over lossy (quality 90) WebP encoding. Smaller alpha overhead means richer images on webpages.

You can find a more detailed compression study for these modes here and sample images in the WebP-Gallery. The bit stream specification has not been finalized, and the encoding and decoding implementations have not yet been optimized for processing speed. We encourage you to try it out on your favorite set of images, check out the code, and provide feedback. We hope WebP will now handle all your needs for web images, and we're working to get WebP supported in more browsers.

Prerendering in the best case speeds up specific processes. When it comes to web browsers the technology could pre-load and render websites to display them faster for the user. This only works if the browser gets the site right. If you look at a standard web search for instance, you will get ten search results by default plus other pages that you could click on. It would be a tremendous waste of processing power and bandwidth if the browser would load all of those pages, especially if the user would only click on one page of the results.

The Google Chrome web browser, and Chromium as well, use prerendering in a limited way. It may be used when you enter a phrase into the Chrome address bar. But which page or pages do get prerendered when this is happening?

That’s easy to find out (thanks to François Beaufort who posted a short demonstration video on YouTube). All you need to do is to open the Google Chrome or Chromium Task Manager to see which pages get prerendered by the web browser.

You can open the Chrome Task Manager with a click on the Wrench icon, the selection of Tools and Task Manager. You can alternatively use the keyboard shortcut Shift-Esc to bring up the Task Manager directly.

Look for Prerender: entries in the Task Manager. The indicator is followed either by the site url that got prerendered or the page title. It may still take time to identify the prerendered link on the page as Google is not displaying the information in the web browser.

Prerendering in the web browser is automatically enabled. Users who do not want to use the feature can disable it the following way. Enter chrome://flags in the address bar and locate the “Prerender from omnibox” option.

Enables prerendering of suggestions from the Omnibox and predicts appropriate network actions (prerendering, Instant, DNS preconnect) by calculating a confidence value for each Omnibox result.

Switch to disabled in the pulldown menu to turn the feature off.

Interested in making your Chrome Extension (or packaged app) talk using synthesized speech? Chrome now includes a Text-to-Speech (TTS) API that’s simple to use, powerful, and flexible for users.

Let’s start with the "simple to use" part. A few clever apps and extensions figured out how to talk before this API was available – typically by sending text to a remote server that returns an MP3 file that can be played using HTML5 audio. With the new API, you just need to add "tts" to your permissions and then write:

chrome.tts.speak('Hello, world!');

It’s also very easy to change the rate, pitch, and volume. Here’s an example that speaks more slowly:

chrome.tts.speak('Can you understand me now?', {rate: 0.6});

How about powerful? To get even fancier and synchronize speech with your application, you can register to receive callbacks when the speech starts and finishes. When a TTS engine supports it, you can get callbacks for individual words too. You can also get a list of possible voices and ask for a particular voice – more on this below. All the details can be found in the TTS API docs, and we provide complete example code on the samples page.

In fact, the API is powerful enough that ChromeVox, the Chrome OS screen reader for visually impaired users, is built using this API.

Here are three examples you can try now:

    TTS Demo (app)
    Talking Alarm Clock (extension)
    SpeakIt (extension)

Finally, let's talk about flexibility for users. One of the most important things we wanted to do with this API was to make sure that users have a great selection of voices to choose from. So we've opened that up to developers, too.

The TTS Engine API enables you to implement a speech engine as an extension for Chrome. Essentially, you provide some information about your voice in the extension manifest and then register a JavaScript function that gets called when the client calls chrome.tts.speak. Your extension then takes care of synthesizing and outputting the speech – using any web technology you like, including HTML5 Audio, the new Web Audio API, or Native Client.

Here are two voices implemented using the TTS Engine API that you can install now:

    Lois TTS - US English
    Flite SLT Female TTS - US English

These voices both use Native Client to synthesize speech. The experience is very easy for end users: just click and install one of those voices, and immediately any talking app or extension has the ability to speak using that voice.

If a user doesn't have any voices installed, Chrome automatically speaks using the native speech capabilities of your Windows or Mac operating system, if possible. Chrome OS comes with a built-in speech engine, too. For now, there's unfortunately no default voice support on Linux – but TTS is fully supported once users first install a voice from the Chrome Web Store.

Now it's your turn: add speech capability to your app or extension today! We can't wait to hear what you come up with, and if you talk about it, please add the hashtag #chrometts so we can join the conversation. If you have any feedback, direct it to the Chromium-extensions group.

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!

Cross-posted on the Google Code Blog

Today we are introducing an early preview of Dart, a class-based optionally typed programming language for building web applications. Dart’s design goals are:

• Create a structured yet flexible language for web programming.

• Make Dart feel familiar and natural to programmers and thus easy to learn.

• Ensure that Dart delivers high performance on all modern web browsers and environments ranging from small handheld devices to server-side execution.

Dart targets a wide range of development scenarios: from a one-person project without much structure to a large-scale project needing formal types in the code to state programmer intent. To support this wide range of projects, Dart has optional types; this means you can start coding without types and add them later as needed. We believe Dart will be great for writing large web applications.

Dart code can be executed in two different ways: either on a native virtual machine or on top of a JavaScript engine by using a compiler that translates Dart code to JavaScript. This means you can write a web application in Dart and have it compiled and run on any modern browser. The Dart VM is not currently integrated in Chrome but we plan to explore this option.

The language comes with a set of basic libraries and tools for checking, compiling, and running Dart code, all of which will evolve further with your participation. We've made the language and preliminary tools available as open source on dartlang.org. Check out the site to give feedback, learn more about Dart, and participate in its development.

We look forward to rapidly evolving Dart into a solid platform for structured web programming.

Are you already a happy user of Chrome Developer Tools but always wanted that particular feature added to make you even more productive? Then we have some exciting news for you: our developer tools are now extensible!

You can now add new panels and sidebar section panes, retrieve network requests data, evaluate scripts on the page being inspected, and add custom audit rules.

The extension support is still experimental, but we wanted to let you know early, so we can incorporate your feedback before releasing the APIs.

Here’s how to get started with writing extensions for Chrome Developer Tools:

• Use the dev channel of Chrome as the APIs are still under development;
• Enable experimental extension APIs using the chrome://flags page;
• List experimental in the permissions list of your extension;
• Add a devtools_page field to your extension’s manifest, e.g:

The developer tools extension pages get access to the chrome.experimental.devtools.* APIs which are described further in our docs. Be sure to check out the sample extensions, which include extensions for jQuery and FirePHP users and a simple audit extension that finds broken links.

For a richer example, you can also check out Page Speed for Chromium, which uses the extensions API to provide Page Speed suggestions right in the Chrome Devtools UI.

We recently expanded the reach of the Chrome Web Store from the U.S. to 24 more countries. Developers from around the world have already launched successful apps in the Chrome Web Store to US users. Now all developers can reach a global user base.

What makes this global reach even more interesting is the global payments infrastructure that goes along with it. The store allows developers from 20 countries to sell apps in the store, and users to buy apps in their local currency. We also recently launched the In-App Payments API, which allows developers (U.S.-only for now; international soon) to sell virtual goods in their apps. Integration is easy and transaction fees are only 5%. Graphicly, an early user of in-app payments, saw its net revenues double after starting to use the API and experienced an even bigger rise in profit margins due to increased conversions and lower transaction fees.

In keeping with our international theme, we’d like to highlight a few developers from different parts of the world who have utilized Chrome’s global reach to find success in the store:

• Audiotool is an online music production app that was built by a team of German developers. They saw the Chrome Web Store as a way to present their app to an international audience. Audiotool’s traffic increased by 20% after launching in the store, and this motivated the team to release another app in the store.

• Psykopaint is the brainchild of French developer Mathieu Gosselin. The Chrome Web Store provided Mathieu an opportunity to get his photo painting app noticed outside of France. Traffic to Psykopaint has jumped by 700% since it launched in the store and Mathieu has found that Chrome Web Store users tend to be more engaged than other users.

• Finally, Nulab, a Japanese company, launched its online diagramming app, Cacoo, in the store to expand its user base outside Japan. In just a few months after Cacoo was released in multiple languages in the Chrome Web Store, the app already accounts for 20% of Cacoo’s user base.

Cross posted at the Google Code blog

This year at the Game Developers Conference (GDC) Online we have organized a Developer Day on Oct. 10th full of Google information for game developers. It will feature hardcore technical information on Google products and platforms delivered by Google engineers and developer advocates. We’ll discuss the latest projects we’re working on and how our online technologies can help you better create, distribute, and monetize games that reach a larger audience than ever before. We’ll present everything from how developers can build hardware accelerated 3D games for the browser with WebGL to the game framework used to bring Angry Birds to the Web.

In addition to the Developer Day, we will also have a booth on the Expo floor on Oct. 11th-12th where we’ll have representatives from the Chrome Web Store, Native Client, WebGL, App Engine, Google+, In-App Payments, Google TV, and AdSense/AdMob demoing technologies and platforms for game developers. Come by booth 503 to try out Google products and ask questions, or hang out in our Google TV lounge.

For more information on our presence at GDC Online, including session and speaker details, please visit http://www.google.com/events/gdc/2011. Hope to see you in Austin!

Not able to attend GDC? Check out Google Game Developer Central to get an overview of Google products and services that are particularly relevant to game developers.

A few months ago, we introduced Non-Admin Google Chrome Frame on the developer channel for testing. We deployed it to the beta channel two weeks ago and we are now bringing Non-Admin to the stable channel. Head over here to install it and let us know how it goes.

If you have installed the developer or beta channel version and wish to switch to the stable version, you'll need to uninstall Chrome Frame and then install via the above link. Note that the uninstall experience is smoothest if you close all Internet Explorer windows prior to uninstalling Chrome Frame.

In addition to Non-Admin Chrome Frame moving to the stable channel, we are rolling out a change to the default Chrome Frame installer; it will now run at Admin level by default and will fall back to Non-Admin mode if the user does not have the necessary permissions on their machine. This will allow all users to download a single installer that just works. This installer is available at the Chrome Frame download page.

As always, we welcome discussions in the Chrome Frame Google group and bug reports on Chromium’s issue tracker.

Yesterday we made a small change in Chrome Web Store’s app upload flow: when you upload new apps and extensions to the Chrome Web Store, or edit one of your existing items, you'll be prompted to provide us with new promotional image assets. We are asking you for these assets so that we can highlight your apps and extensions in a brand new store layout that our team is working on.

What's new:

• (Required) You’ll need to provide us with a large rectangular image to identify your app, in addition to assets you already provide - your app icon and at least one screenshot.
• (Optional) You can provide us with an even larger rectangular image format as well.

What's different

• The screenshot dimensions have grown larger with a wider aspect ratio.
• The (optional) marquee image dimensions have also grown larger.

What's the same

• The specification and dimensions for the icon file

To make things easier, we only require screenshots in the new dimensions going forward -- we'll automatically scale them as needed to make them visible in the current store layout. You can read the details about the new requirements on our image guidelines page. If you have any questions on these changes, feel free to reach us at our discussion group.

Cross posted at the Google Code blog

This post almost wasn’t written.

I’ve been a bit too busy playing and testing new browser-based games such as Monster Dash, Angry Birds, and the newly released SONAR. Bigger and better games are coming to the browser rapidly (and just wait until Native Client with 3D lands in Chrome), and it’s hard to keep up with the technology and scene. So what better way to bring everyone together to share stories and keep up to date than to hold a conference dedicated to HTML5 game development?

New Game, the first North American conference for HTML5 game developers, is now open for registration. You are invited to join hundreds of HTML5 game developers for two days of technical sessions and case studies from developers and publishers who brought their games to the open web platform. The event will take place November 1-2, 2011 at the beautiful Yerba Buena Center for the Arts in San Francisco, CA.

This year, New Game looks at what is possible in the browser today. Sessions will focus on the technologies that have elevated the browser-based gaming experience, such as WebGL, Canvas, and JavaScript performance techniques. In addition, the conference will feature sessions exploring and analyzing lessons-learned from recent HTML5 game launches.

New Game is honored to have Rich Hilleman, EA’s Chief Creative Officer, keynote the event. The schedule also includes sessions from Mozilla, Spil, Opera, Google, Bocoup, GameSalad, Moblyng, and others. After the first day, we’ll network with our colleagues and share high scores at the New Game party, open to all registered attendees.

For more information on New Game, including session and speaker details, please visit www.newgameconf.com and follow @newgameconf for the latest news. Google, the premier sponsor, and conference director Bocoup invite you to take advantage of early bird registration pricing, available for a limited time.

The future of gaming is in your browser, so I’ll see you at New Game! Now if you’ll excuse me, it’s time to get back to my SONAR tab.

Wouldn’t it be great if you could create web apps using your existing C and C++ code? Native Client lets you do just that, and it is now enabled for Chrome Web Store apps in Google Chrome’s beta channel.

Native Client apps live on the web platform, so you don’t need to create separate versions of your app for each operating system. Rather than relying on OS-specific APIs, Native Client apps use Pepper, a set of interfaces that provide C and C++ bindings to the capabilities of HTML5. This means that once you’ve ported your code to Native Client, it will work across different operating systems, and you only need to maintain one code base.

Today Native Client supports the Pepper APIs for 2D graphics, stereo audio, URL fetching, sandboxed local file access (File API), and asynchronous message passing to and from JavaScript. In future releases we will be adding support for hardware accelerated 3D graphics (OpenGL ES 2.0), fullscreen mode, networking (WebSockets and peer-to-peer connections), and much more. As new capabilities are added to HTML5 and Pepper, they will become available to Native Client.

This functionality does not come at the expense of security. To ensure that Native Client is as safe as JavaScript, Native Client code is isolated from the operating system by two nested security sandboxes: the Native Client sandbox and the Chrome sandbox. And unlike NPAPI plugins or ActiveX controls, Native Client apps do not have access to the underlying OS APIs.

We encourage you to start developing apps with Native Client. You can download the SDK and find tutorials, examples, API documentation, and our FAQ on the Native Client site. Once version 14 of Chrome hits stable channel, you’ll be able to upload your Native Client apps to the Chrome Web Store, where you can reach Chrome’s 160 million users.

The next milestone for Native Client is architecture independence: Portable Native Client (PNaCl) will achieve this by using LLVM bitcode as the basis for the distribution format for Native Client content, translating it to the actual target instruction set before running. Until then the Chrome Web Store will be the only distribution channel for Native Client apps. This will help us ensure that all Native Client apps are updated to PNaCl when it’s ready – and in the meantime avoid the spread of instruction set architecture dependent apps on the web. We’ll be providing updates on the progress of PNaCl on this blog.

In today’s browser ecosystem, web apps are completely disconnected or require the use of complicated APIs in order to make use of a third-party service, e.g., posting a comment to Twitter from your custom publishing domain. What if we could give sites the ability to leverage these services without any knowledge of the chosen service, except that it provides some set of predefined functionality?

Android OS addresses this problem with Intents, a facility for late run-time binding between components in the same or different applications. In the Intents system, the client application requests a generic action, e.g. share, and specifies the data to pass to the selected service application. The user is given a list of applications which have registered that they can handle the requested intent. The user-selected application is created in a new context and passed the data sent from the client, the format of which is predefined for each specific intent type.

We are hard at work designing an analogous system for the web: Web Intents. This web platform API will provide the same benefits of Android Intents, but better suited for web applications. When designing the system, we have first and foremost been interested in creating a simple, easy-to-use API. With Web Intents, you will be able to connect your web app to a service with as little as two lines of code! Chrome will perform the heavy lifting for you. As with Android, Web Intents documents an initial set of intent actions (edit, view, share, etc.) that likely cover the majority of use cases on the web today; however, as the web grows and sites provide more functionality, new intent actions will be added by services that document these intents, some more popular than others. To foster development and use of intents, we plan to create a site to browse existing intents and add new intents.

Consider an online photo storage site run by a cash-strapped startup: the developers don’t have the resources to add image editing abilities to their app, but they feel the site won’t be a hit without it. The Web Intent system will make it easy for them to offer this with little effort.

var intent = new Intent(Intent.EDIT, ‘image/png’, getImageDataURI());
window.navigator.startActivity(intent, loadEditedImage);

// This callback will be called when the service replies with the edited
// image data.
function loadEditedImage(data) {
var image = document.getElementById(‘image’);
setImageData(image, data);
}

When the user visits her favorite memegen service, the site will request registration to handle the EDIT intent for files of type ‘image/*’ using the following declaration:

When the user initiates the EDIT action, this service is presented to the user, along with other registered image editors. Once the user selects Meme Generator, the referenced site is opened in a new context and is able to load the image data from the intent payload:

var intent = window.intent;
memeImg.src = intent.data;

memegenForm.onsubmit = function() {
// Transform the image - meme it.
addMemeTaglines(memeImg, memeTopText, memeBottomText);

// Send the generated meme back to the client.
intent.postResult(getImageData(memeImg));
};

Once postResult() is called, the Meme Generator context is closed and the output data is sent back to the client via the callback passed to startActivity().

Mozilla is also actively exploring this problem space. In fact we’re working closely with Mozilla engineers to unify our two proposals into one simple, useful API. Visit the examples page to try out the feature in any current browser. To explore using the API in your site, check out out the JavaScript shim, which provides an implementation of the API for browsers that have not implemented this feature. We are rapidly prototyping this feature, so check back soon for an announcement when Web Intents is available behind a flag in Chrome.

Since Google I/O, we’ve been working hard to make the Chrome Web Store available to more users around the world as well as to provide additional monetization opportunities for developers. Today, we're happy to share progress in both of these areas.