(Cross-posted on the Official Google Code and Commerce Blogs)

Since Google In-App Payments launched in July for developers in the United States, we’ve received great feedback on how easy it is to integrate as well as how simple it is for consumers to use. While the API has been off to a strong start, there’s been a growing demand for availability outside of the United States.

So starting today, we are opening developer enrollment for Google In-App Payments to 17 additional countries. In addition to the United States, developers from Australia, Austria, Belgium, Canada, Denmark, Finland, France, Germany, Ireland, Italy, Japan, the Netherlands, Norway, Portugal, Spain, Sweden, and the United Kingdom can now use the Google In-App Payments API to incorporate an in-context payment experience into applications on the Chrome Web Store and their own sites.

Developers using In-App Payments are seeing strong conversions and revenue streams thanks to these key features:

• Ease of use: the short payment process for consumers takes place right in the developer’s app or site.
• Large existing user base: there are millions of Google Wallet online users in over 140 countries.
• Low fees: developers pay just 5% on all transactions.

You can get started accepting payments in your web apps by following the tutorial and get answers to any questions in the forum. We look forward to expanding to even more countries in the future, as well as continuously working to improve the Google In-App Payments experience.

Posted by Pali Bhat, Product Manager, Google Commerce Team

Updated on December 14th with the video of the event.

Since we launched Native Client late last summer, our team has been working hard to make the technology more useful to developers. Yesterday at an event held at Google we shared the progress we’ve made towards this goal and showcased work from some of the early adopters of the technology, including Square Enix, Unity Technologies, and Bungie.



One code base for all OSs
In September, we started supporting a set of core Pepper interfaces, suited for 2D graphics, audio, and compute-intensive applications. Since that release, we’ve shipped additional APIs and capabilities, providing native code with more of the capabilities available from JavaScript. These include hardware-accelerated 3D graphics via OpenGL ES 2.0, a mouse lock API, a full-screen API, and much more. One example of the kind of experience Native Client can currently support is Bastion, an award-winning role-playing game from Supergiant Games. Previously limited to Microsoft Windows® and Xbox® systems, the Native Client port of Bastion allows Supergiant to reach users on all popular desktop operating systems, with the safety and simplicity of the web.

Easy porting of previous work
If you have existing code bases in C, C++, or C#, Native Client now allows you to port your existing apps to the web while maintaining just one code base. This was particularly appealing to Spacetime Studios. They ported their multiplayer online game Star Legends to the web in less than two weeks from an existing code base of more than half a million lines of code. The side benefit of being able to maintain their existing development and testing infrastructure further accelerated their delivery of a shipping title.

More choices of programming languages
The community is actively involved in Native Client, porting some of the most popular application middleware. Ports include Unity and Moai game engines, programming language environments Mono and Lua, audio middleware such as fmod and Wwise, as well as the Bullet physics engine. These Native Client ports make the web more accessible to hundreds of thousands of application developers. At the event, we showcased upcoming applications from Heartwood, Silvertree, Exit Strategy, and Dedalord, who used those tools to bring their apps to the web with very little effort. We’ll continue to work with the community to get even more languages and middleware systems ported to Native Client.

We recognize that building a Native Client app is only the start of a successful app. That’s why we’ve enabled distribution of Native Client-based apps via the Chrome Web Store. The Chrome Web Store gives developers a simple, effective strategy to reach over 200 million active users of Google Chrome.

If all this sounds exciting, please visit our new documentation site at gonacl.com. There you’ll find a growing collection of tutorials, examples, videos, reference documentation, and much more.



Questions or suggestions? Join us in the discussion forums. We look forward to seeing some great new apps from Native Client developers.

Posted by Christian Stefansen, 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

Today we are announcing the release of Chrome’s new incremental garbage collector (GC) which dramatically improves interactive performance of web apps and HTML5 games.

The V8 project has made huge progress improving peak performance of web apps. With the advent of technologies like WebGL we’re seeing the emergence of highly interactive and graphically intensive apps, such as the new version of Google Maps, new games and demos. But with these new uses comes a need for better interactive performance in JavaScript.

Avoiding pauses is vital to achieving good interactive performance. Previously, garbage collection pause times depended on the amount of memory used. Therefore, large interactive apps were impacted by pauses that caused hiccuping. V8’s new GC reduces pause times dramatically while maintaining great peak performance and memory use.

To evaluate the new GC, we took the most memory intensive peak performance test from the V8 Benchmark Suite and used it to make a stress test for interactive performance. In our testing the maximum time to render a frame including pause time is reduced from 272ms to 50ms.

The new GC in Chrome improves interactive performance and opens up new possibilities for the interactive web. If you are developing highly interactive web apps or games, please try it out and share your experiences. It is available now on the dev channel.

Posted by Vyacheslav Egorov and Erik Corry, Software Engineers

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.

Posted by Jyrki Alakuijala, Vikas Arora, and Urvang Joshi, Software Engineers

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.

Posted by Dominic Mazzoni, 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