Today’s Chrome Beta channel release introduces a new HTML attribute for responsive images and the unprefixed version of the JavaScript Web Audio API. Unless otherwise noted, changes apply to desktop versions of Chrome and Chrome for Android.

The srcset attribute

Today the web is used on laptops, TVs, phones, tablets and other devices with heterogeneous screen sizes and device pixel ratios. Serving the same image resources to all devices can lead to slower page load times, wasted bandwidth and improperly formatted content.

srcset will help resolve this problem by letting Web developers provide multiple resources in varying resolutions for a single image. The browser can then pick the resource that matches the device's capabilities. Here’s an example of the code:


Note that the src attribute is not needed for browsers that support srcset, but it’s good for backwards compatibility. Kudos to external Blink developer Yoav Weiss for implementing and driving consensus for this feature. Stay tuned for the <picture> element, which will also help web developers with responsive design.

Unprefixed Web Audio

The Web Audio API is a high-level JavaScript API for processing and synthesizing audio in web applications. We shipped the prefixed version of the API a few years ago. Starting with this release, the unprefixed API entry points audioContext and offlineAudioContext will be available in addition to their prefixed counterparts. Legacy methods such as createGainNode and createDelayNode are deprecated.

This brings Chrome’s implementation of Web Audio in alignment with the W3C draft specification and offers compatibility with the Web Audio support in Firefox. Please switch to the unprefixed versions soon, as the prefixed versions are now officially deprecated and will be removed in a future release.

UPDATE April, 9th: Unprefixed Web Audio will ship in Chrome 35, not Chrome 34.

Other web platform changes in this release

• The font-variant-ligatures CSS property allows developers to control ligatures in text.
• A variety of infrequently used web platform features have been deprecated or removed. For a complete list, see the list of Blink “intents”.
• As we’ve previously discussed, Chrome will now offer to remember and fill password fields in the presence of autocomplete=off. This change does not affect non-password fields.

If you’ve ever been curious about the usage of HTML and JavaScript features, check out the updated chromestatus.com/metrics, which now shows the percentage of page loads that use certain web platform features.

As always, visit chromestatus.com/features for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates!

Posted by Raymond Toy, Software Engineer and Audiofile [sic]

Extension developers, take note: if you are not yet hosting your extension in the Chrome Web Store, now is the time to do so. Back in November as part of our ongoing effort to protect Chrome users from malicious and unwanted software, we announced that we will require Chrome extensions to be hosted on the Chrome Web Store. Earlier this month we started enforcing this policy for the Chrome Beta channel on Windows, and have been gathering feedback from users and developers.

Some developers have requested more time to complete this transition, so we've decided to extend the window until May 1 before we start enforcing this policy for the Windows Stable channel. As a reminder this policy will only apply to Windows Beta and Stable channel users. You can continue to use off-store extensions on Windows Dev and Canary, as well as on Mac, Linux and Chrome OS. Developer and enterprise policy use cases are similarly unaffected.

To minimize potential disruption to your users, please be sure to register your extension in the Chrome Web Store before May 1. After this time extensions outside the Chrome Web Store will be automatically disabled. If you register after the deadline your users will need to manually re-enable or re-install your extension to regain functionality. Please take a look at our FAQs, and if you need any help or support through this transition, reach out to us on our mailing list.

Update May 16, 2014: This will begin being enforced on Windows stable channel shortly after Chrome 35 is released, near the end of May.

Posted by Erik Kay, Engineering Director

We aim to make Chrome the fastest browser possible. One way V8 helps with this goal is by compiling JavaScript into native machine code to execute scripts quickly. Historically, Chrome compiled JavaScript on the main thread, where it could interfere with the performance of the JavaScript application. In the latest Chrome Beta we've enabled concurrent compilation, which offloads a large part of the optimizing compilation phase to a background thread. The result is that JavaScript applications remain responsive and performance gets a boost.

Let’s have a look under the hood of V8 to understand how this works. To reduce the overall time spent compiling, V8 defers compilation of JavaScript functions until immediately before they are executed the first time. This compilation phase is fast but doesn’t focus on optimizing the code, just on getting it done quickly. In V8, pieces of code that are executed very often are compiled a second time by a specialized optimizing compiler. This second compilation pass makes use of many advanced optimization techniques, meaning it takes more time than the first pass but delivers much faster code.

Until now, V8 took turns compiling optimized Javascript code and executing it. For large pieces of code this could become a nuisance, and in complex applications like games it could even lead to stuttering and dropped frames. Concurrent compilation tackles this issue.

The graphs below show excerpts of V8’s vital signs when running Mandreel, part of the Octane benchmark suite, on the Nexus 5 phone. The graphs have been created using our new profiling visualization tool. The black bar represents execution of JavaScript, and ideally would be solid.

The first graph shows V8 running without concurrent compilation. V8 is fully occupied with optimizing a large piece of code, causing an execution pause of more than 600ms.

By enabling concurrent compilation, V8 still optimizes a large piece of code, but does it in a background thread. Execution continues alongside compilation, providing for a smoother user experience. For instance, concurrent compilation improved the Mandreel score of Octane 2.0 by 27% on a Nexus 5 and made graphic-intensive applications such as the Epic Citadel Demo run even smoother in Chrome.


Concurrent code compilation is another step towards reducing latency in Chrome and is part of various ongoing efforts to deliver more responsive, smoother web applications.

Posted by Yang Guo, Multi-threaded V8 Engineer

[Cross posted from the Google Developers Blog]

By John Affaki, Engineering Manager

Updated Feb. 14 to say that the Google Cast SDK for Android is now available.

Back in July we announced the developer preview of the Google Cast Software Development Kit (SDK), the underlying Chromecast technology that enables multi-screen experiences across mobile devices (phones, tablet, laptops) and large-screen displays. Starting today, the Google Cast SDK is available for developing and publishing Google Cast-ready apps.

The Google Cast SDK is simple to integrate because there’s no need to write a new app. Just incorporate the SDK into your existing mobile and web apps to bring your content to the TV. You are in control of how and when you develop and publish your cast-ready apps through the Google Cast developer console. The SDK is available on Android and iOS as well as on Chrome through the Google Cast browser extension.
Receiver app support
You have many options for displaying content on Chromecast. For simple media applications, you can use the default media player that can play back HTML5 media content. You can also customize it with your own branding and style using CSS.

For non-media applications, or for more flexibility and design options, you can build your own custom receiver application using standard web technologies. With a custom receiver you can build virtually any application while including support for many streaming protocols, including MPEG-DASH, HLS, and Microsoft Smooth Streaming, all of which are available in the Media Player Library.

Sample apps
To make it easier for you to provide an optimized user experience on the TV screen, we have created sample apps for Android, iOS and Chrome. For Android, you’ll find a Cast Companion library to make your integration of Google Cast even easier.

Availability
All Chromecast devices have already been updated to the latest software with support for the Google Cast SDK. The Google Cast extension for Chrome supporting the latest SDK will start rolling out today. The Google Cast SDK for Android is now available on Android devices worldwide as part of the Google Play services 4.2 update. The Google Cast SDK for iOS is available starting today. You can find the details for each platform in our documentation.

Head over to the Google Cast Developers site to get started with the Google Cast SDK. We look forward to your feedback and seeing what you develop with the SDK.

Happy casting!


John Affaki manages the client software and services teams for Google Cast. He never grew out of childhood and spends his free time playing video games and reading comic books, but is glad to have some real kids now.