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.
We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times. SSL False Start reduces the latency of a SSL handshake by 30%1. That is a big number. And reducing the cost of a SSL handshake is critical as more and more content providers move to SSL.
Our biggest concern with implementing SSL False Start was backward compatibility. Although nothing in the SSL specification (also known as TLS) explicitly prohibits FalseStart, there was no easy way to know whether it would work with all sites. Speed is great, but if it breaks user experience for even a small fraction of users, the optimization is non-deployable.
To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.
To investigate the failing sites, we implemented a more robust check to understand how the failures occurred. We disregarded those sites that failed due to certificate failures or problems unrelated to FalseStart. Finally, we discovered that the sites which didn’t support FalseStart were using only a handful of SSL vendors. We reported the problem to the vendors, and most have fixed it already, while the others have fixes in progress. The result is that today, we have a manageable, small list of domains where SSL FalseStart doesn’t work, and we’ve added them to a list within Chrome where we simply won’t use FalseStart. This list is public and posted in the chromium source code. We are actively working to shrink the list and ultimately remove it.
All of this represents a tremendous amount of work with a material gain for Chrome SSL users. We hope that the data will be confirmed by other browser vendors and adopted more widely.
1Measured as the time between the initial TCP SYN packet and the end of the TLS handshake.
