Chromium Blog: April 2014
COLLECTED BY
A longitudinal web archival collection based on URIs from the daily feed of Media Cloud that maps news media coverage of current events.
The Wayback Machine - https://web.archive.org/web/20210316083435/https://blog.chromium.org/2014/04/
In 2009, we developed ThreadSanitizer (aka TSan), a runtime data race detector based on binary translation . The tool helped find thousands of threading errors in various projects, including almost 180 bugs in Chromium. In 2010, we started experimenting with compiler-based instrumentation instead of binary translation, and once the approach had proven itself, our team redesigned ThreadSanitizer from scratch, focusing on compile-time instrumentation for greater speed and accuracy.
ThreadSanitizer v2 , is now part of both LLVM and GCC . Not only is it able to detect data races in C++ and Go code, but it is also able to report synchronization issues like deadlocks, unjoined threads, destroying locked mutexes, use of async-signal unsafe code in signal handlers, and others.
incorrect synchronization in LazyInstance , incorrect lock-free queue implementation , and issues with concurrent sweeping in V8 .
races on the WebKit strings , garbage collection in Blink , a use-after-free in Blink , a handful of reports in WebRTC and many more. This has also improved bug reproducibility: the more times the test is repeated, the higher the chance to reproduce a flaky bug.
ClusterFuzz and adding regular testing for various Chromium subprojects to catch new regressions quickly.
ThreadSanitizer page contains all of the information necessary to start using the tool in your project. The tool is easy to use and can be integrated with any buildsystem: just add a single compile-time flag and run the program to see the error reports. For Chromium developers there’s a special page with instructions on dev.chromium.org .
Today’s Chrome Beta channel release includes a slew of new developer features to help you make richer, more compelling web content and apps, especially for mobile devices. Unless otherwise noted, changes described below apply to Chrome for Android, Windows, Mac, Linux, and Chrome OS.More developer control over touch and zoom input touch-action CSS property offers developers a declarative mechanism to selectively disable touch scrolling, pinch-zooming, or double-tap-zooming on parts of their web content. Use cases include precise control over the dreaded 300ms click delay on mobile , reliable side-swipe UIs, and high-fidelity polyfills of Pointer Events . It’s also a prerequisite for future optimizations to enable scrolling and zooming that never block on the main thread . Update May 20th: touch-action has been delayed until Chrome 36.mouse scroll wheel events with the ctrlKey modifier set . There are many sites that want to do something more appropriate for the user than trigger browser zoom. For example, when a user holds control and scrolls over a map in Google Maps, they almost certainly want to zoom in on the map, not invoke browser zoom to zoom the page. This change will enable such a use case.New JavaScript functionality ECMAScript 6 standard . Together, they will help JavaScript developers write application logic that is easier to read, more powerful, and more memory efficient. Promise represents a value that may not be available yet but will be known at some point in future. With Promises, you can write cleaner asynchronous code. WeakMaps and WeakSets allow you to create efficient, garbage-collected data structures. In both, references to objects are held weakly: if there is no other reference to an object stored in the WeakSet, it can be garbage collected. This helps avoid memory leaks.Object.observe lets you observe changes to JavaScript objects. Your callback can observe multiple objects and will receive all changes to any objects in a single asynchronous call. This is especially useful for framework authors implementing data-binding .Unprefixed Shadow DOM Web Components umbrella. It brings reliable composition of user interface elements to the web platform and allow developers to:
Scope their HTML markup, CSS, hiding the implementation details of complex components.
Build their own first-class elements and APIs just like the <video> or <audio>, when combined with Custom Elements
With Shadow DOM, web frameworks can stop worrying about their widgets inadvertently breaking pages by using conflicting CSS selectors, class or id names, and start relying on DOM as the interoperable way of building components.made available in Chrome 25 , so if you were already using the prefixed Shadow DOM API please take a look at the latest documentation as well as the up-to-date HTML5 Rocks articles and look for deprecation warnings.Other new features in this release
CSS Font Loading can be used to dynamically load font resources. It gives developers more control over the user experience on pages that use Web Fonts. For instance, you can ask Chrome to start downloading the web fonts you'll need on demand and be notified when they become available.
The SVG 'paint-order' property offers a way to control the order in which fill, stroke and markers are painted.
The unprefixed version of the Web Audio API .
Removed features HTMLVideoElement-specific prefixed fullscreen API , TextTrackCue constructor , <isindex> , Legacy Web Notifications ,
document.createAttributeNS , support for NPAPI on Linux , and Attr.isId, ownerElement, prefix setter . If you’d like to hear more about these changes or participant in discussions, please chime in our mailing list and look for "Intent to Remove" or “Intent to Deprecate” threads.Recently deprecated features window.showModalDialog , which will be removed in our next release, Chrome 36. Please read Opera’s explanation of the change to learn more. Other deprecated features include Element.setAttributeNodeNS , overflowchanged Event , HTMLSourceElement.media, MediaError.MEDIA_ERR_ENCRYPTED , Prefixed media source extensions , and webkitRequestAnimationFrame . Support for these features will be completely removed from Chrome in a future release.chromestatus.com/features for a complete overview of Chrome’s developer features, and circle +Google Chrome Developers for more frequent updates!Rick Byers , Software Engineer and Touch API Tamer
Today's release of the Dart SDK version 1.3 includes a 2x performance improvement for asynchronous Dart code combined with server-side I/O operations. This puts Dart in the same league as popular server-side runtimes and allows you to build high-performance server-side Dart VM apps.
measured request-per-second improvements using three simple HTTP benchmarks: Hello, File, and JSON . Hello, which improved by 130%, provides a measure for how many basic connections an HTTP server can handle, by simply measuring an HTTP server responding with a fixed string. The File benchmark, which simulates the server accessing and serving static content, improved by nearly 30%. Finally, as a proxy for performance of REST apps, the JSON benchmark nearly doubled in throughput. In addition to great performance, another benefit of using Dart on the server is that it allows you to use the same language and libraries on both the client and server, reducing mental context switches and improving code reuse.
The data for the chart above was collected on a Ubuntu 12.04.4 LTS machine with 8GB RAM and a Intel(R) Core(TM) i5-2400 CPU, running a single-isolate server on Dart VM version 1.1.3, 1.2.0 and 1.3.0-dev.7.5. The source for the benchmarks is available.
We are excited about these initial results, and we anticipate continued improvements for server-side Dart VM apps. If you're interested in learning how to build a web server with Dart, check out the new Write HTTP Clients and Servers tutorial and explore the programmer's guide to command-line apps with Dart . We hope to see what you build in our Dartisans G+ community .
Last April we introduced Blink as the new rendering engine for Chromium. Since then, the project has grown to include over 200 active contributors, and code complexity has been reduced significantly. We’ve also made encouraging progress on our top priority for 2014: mobile web performance.
our mailing list within Blink’s first few months. Each week, we now see on average 23 new discussion threads and 5 new “intents” to change the web API surface. We’re honored that 41% of our “intents” have come from folks outside of Google, and 33% of our active contributors are non-Googlers. We’re especially excited about recent contributions like Yoav Weiss ’s implementation of the <picture> element , the Opera team’s prolific improvements and feature removals , Intel’s performance work , Adobe’s continued work on making the web awesome with CSS Shapes and other graphics and layout work , Samsung’s investment in mobile functionality, and more.
built the Chromium Feature Dashboard , a tool for staying up-to-date on Blink’s web API surface. It’s currently tracking implementation of 168 web platform features and anonymous usage statistics for 295 JavaScript APIs & HTML tags and 428 CSS properties . We use these usage statistics to see which features can be safely deprecated . In the offline world, last September we held our first bi-annual contributors’ conference with over 160 participants from 10+ organizations.
only supported port is Chromium . In aggregate, nearly half the codebase has been eliminated since work on Blink began last year. Notable simplification efforts include unifying CSS and SVG animations with the Web Animations engine, replacement of our WebIDL compiler , factoring of a blink_platform layer out of core code , and continued work on a C++ garbage collector .
speed up rendering , minimize binary size , reduce input latency , preserve battery power , shrink memory consumption , and more.
Chromium’s compositor . We’re now much more careful to do work for Blink only just before Chrome draws to the screen, avoiding wasting CPU cycles generating results that will overwritten before the next frame is drawn anyway. Through tighter integration, we’ve also achieved 50% savings in compositing updates that change only CSS transforms . This is just the beginning of our performance work; we expect even further improvements from newer efforts like GPU rasterization and better scheduling .
Join us or follow along to stay in touch!
Last year we released Google Cloud Messaging (GCM) for Chrome that enabled Chrome Apps and extensions to receive push messages from their server-side components. While it provided developers with powerful new capabilities, it was not compatible with Google Cloud Messaging for Android, which led to inconsistencies in the feature sets supported for both platforms. Today we are releasing a developer preview of the new chrome.gcm API . The API shares server-side infrastructure with GCM for Android, which means cloud messaging has to be implemented only once on the server side for both Android and Chrome Apps.
Chrome Canary and the Dev Channel . You can learn more about writing GCM-enabled Chrome Apps from our documentation . For a quick start, you can check out the GCM sample available on GitHub.
Stack Overflow , our G+ Developers page , or our developer forum .
