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.
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
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’re looking forward to seeing your feedback on the APIs and, of course, cool extensions coming to life!
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.
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.
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.
Please note that the new protocol is incompatible with one which Chromium previously supported (draft-ietf-hybi-thewebsocketprotocol-00), so existing WebSocket-based services may break. Please upgrade your servers to ones which support HyBi 10. Existing JavaScript code still works once the protocol version used by the browser and server match.
The new protocol introduces some exciting new features like binary message support and compression support, but these are not quite ready yet in Chrome and will come shortly - hang tight!
See the specs and discussion at W3C and WHATWG (spec, whatwg list) and IETF (spec, HyBi list) for more detail about the new protocol.
We’re more than happy to hear your feedback, and encourage you to file any bugs you find on our issue tracker.
Snapshots contain every object from the JavaScript heap, so you can explore them in detail and find out how much memory every object of your application consumes. The heap profiler also offers the following features:
snapshots diffing
grouping objects by constructor
calculating retained sizes of objects
showing dominators tree
revealing paths to GC roots or window objects
In addition, the heap profiler takes into account native DOM nodes, and allows you to uncover DOM-related memory leaks.
It is also possible to measure how much JavaScript memory is currently used from within the page itself. You can sample values from the performance.memory window property at different points of your application lifetime. Please note, that the property does not report anything, unless you run Chrome with --enable-memory-info command-line argument.
For a more complete reference on working with the Chrome Developer Tools heap profiler, check out the tutorial.
[1]: How to invoke the context menu in the Chrome Task Manager:
WebP's compression algorithms have been significantly improved while remaining completely
compatible with the previous releases. We hope the quality of a few sample images in the new gallery will delight you.
On the decoding side, we have integrated a fancy upsampler. Fancy upsampling reduces the pixelation of strong edges. You can see this feature when you zoom in, for example on a WebP image with red edges converted from this PNG original:
Original image in PNG format
Without fancy upsampling: strong stair-like pattern
With fancy upsampling: smoother edge
We also introduced the ability to incrementally decode the data as your computer downloads it from the web, a feature that allows the browser to display images without having to wait for the whole file to download. This feature is already enabled in Chrome 12.
On the encoding side, to further improve quality, we focused on segmenting the picture into areas with similar compressibility. For each of these segments, we tune the amount of compression and filtering differently, and bits are redistributed where they are most useful. Take for instance the image reproduced below [1]:
The easy segment contains lot of disparate signals and can be compressed more than the difficult one, which will be assigned more bits. In this example, the encoder only used two segments. By using even more segments (up to four), WebP is now able to retain many of the original details of the image [2]. This is in contrast to the frequent ringing artifacts one can clearly see in JPEG images.
The uneven distribution of bits between difficult and easy area is controlled in the new encoder using the -sns parameter, short for Spatial Noise Shaping. Its value can be set from 0 to 100 (0 meaning OFF) and with a default of 80. Note that when you enable SNS, PSNR may be degraded, but the overall visual quality is much improved.
We’ve added simple encoding and decoding example binaries to the libwebp library. In addition, we’ve added JNI support that allows Java programs to decode WebP images. Next up is transparency, also known as Alpha channel; we’re experimenting with it now and planning to add it to the next stable version of the codec. In parallel, we continue to improve the codec’s speed and will release a complete specification for the metadata format.
Increased adoption
WebP is now natively supported in Chrome and Opera. Google products including Gmail and Picasa Web Albums, have also added support to WebP so you can share, send and receive WebP images. WebP support is coming to AppEngine. In addition, Google Instant Previews now store images in WebP to reduce their storage needs.
Users that want to manipulate WebP images can now do so using software developed by the community including Pixelmator, ImageMagick, the WebP format plugin for Photoshop and the Java VP8 decoder. The open-source community has also contributed support for Mac OS X with MacPorts packages, Linux Debian, OpenSUSE and Gentoo packages and the Apache HTTP Server. On Windows, users who want to view WebP images natively, can download the WebP codec. This codec brings WebP support to such software as Microsoft Office 2010, Windows Media Center and Photo Edit.
The new features, quality improvements and increased adoption of WebP get us excited about its future. As always, we’re looking for more feedback as well as code contributions from the community. Let us know on the mailing list how your experiments are panning out and what new features you’d like to see in the future.
Image credits:
[1]: "Kayaker at Ekstremsportveko 2010, Voss". Image Author: Kjetil Birkeland Moe. Reproduced with permission of the author. PNG source, and Blog post by author with comparison of JPEG and WebP.
