Announcing Google Radio PHY Test, aka “Graphyte”, as part of the Chromium Project

With many different Chromebook models for sale from several different OEMs, the Chrome OS Factory team interfaces with many different Contract Manufacturers (CMs), Original Device Manufacturers (ODMs), and factory teams. The Google Chromium OS Factory Software Platform, a suite of factory tools provided to Chrome OS partners, allows any factory team to quickly bring up a Chrome OS manufacturing test line.

Today, we are announcing that this platform has been extended to remove the friction of bringing up wireless verification test systems with a component called Google Radio PHY Test or “Graphyte.” Graphyte is an open source software framework that can be used and extended by the wireless ecosystem of chipset companies, test solution providers, and wireless device manufacturers, as opposed to the traditional approach of vendor-specific solutions. It is developed in Python and capable of running on Linux and Chrome OS test stations with an initial focus on Wi-Fi, Bluetooth, and 802.15.4 physical layer verification.

Verifying that a wireless device is working properly requires chipset- and instrument-specific software which coordinate transmitting and measuring power and signal quality across channels, bandwidths, and data rates. Graphyte provides high-level API abstractions for controlling wireless chipsets and test instruments, allowing anyone to develop a “plugin” for a given chipset or instrument.

Graphyte architecture.

We’ve worked closely with industry leaders like Intel and LitePoint to ensure the Graphyte APIs have the right level of abstraction, and it is already being used in production on multiple manufacturing lines and several different products.

To get started, use Git to clone our repository. You can learn more by reading the Graphyte User Manual and checking out the example of how to use Graphyte in a real test. You can get involved by joining our mailing list. If you’d like to contribute, please follow the Chromium OS Developer Guide.

To get started with the LitePoint Graphyte plugin, please contact LitePoint directly. To get started with the Intel Graphyte plugin, please contact Intel directly.

Happy testing!

By Kurt Williams, Technical Program Manager

Why I contribute to Chromium

This is a guest post by Yoav Weiss who was recently recognized through the Google Open Source Peer Bonus Program for his work on the Chromium project. We invited Yoav to share about his work on our blog.

I was recently recognized by Google for my contributions to Chromium and wanted to write a few words on why I contribute to the project, other rendering engines and the web platform in general. I also wanted to share how it helped me evolve as a developer and why more people should contribute to the web platform for their own benefit.

The web platform

I’ve written before about why I think the web platform is an extremely important asset for humanity and why we should make sure it'll thrive for years to come. It enables the distribution of knowledge to the corners of the earth and has fundamentally changed our world. Yet, compared to the amount of users (billions!) and web developers (millions), there are only a few hundred engineers working on maintaining and improving the platform itself.

That means that there are many aspects of the platform that are not as well maintained as they should be. We're at a real risk of a "tragedy of the commons" scenario, where despite usage and utility, the platform will collapse under its own weight because maintaining it is nobody's exclusive problem.

How I got started

Personally, I had been working on web performance for well over a decade before I decided to get more involved and lend my hand in building the platform. For a large part of my professional life, browsers were black boxes. They were given to us by the browser gods and that's what we had to work with for the next few years. Their undocumented bugs and quirks became gospel, passed from senior engineers to their juniors.

Then at some point, that situation changed. Slowly but surely, open source browsers started picking up market share. No longer black boxes, we can actually see what happens on the inside!

I first got involved by joining the responsive images discussions and the Responsive Images Community Group. Then, I saw a tweet from RICG's chair calling to develop a prototype of the current proposal to prove its feasibility and value. And I jumped in.

I created a prototype using Chromium and WebKit, demoed it to anyone that was interested, worked on the proposals and argued the viability of the proposals' approach on the various mailing lists. Eventually, we were able to get some browser folks on board, improve the proposals and their fit to the rest of the platform, and I started working on an implementation.

The amount of work this required was larger than I expected. Eventually I managed to ship the feature in Blink and Chromium, and complete large parts of the implementation in WebKit as well. WOOT!

Success! Now what?

After that project was done, I started looking into what I should do next. I was determined to continue working on browsers and find a gig that would let me do that. So I searched for an employer with a vested interest in the web and in making it faster, who would be happy to let me work on the platform's client - the web browser.

I found such an employer in Akamai, where I have been working as a Principal Architect ever since. As part of my job I'm working on our performance optimization features as well as performance-related browser features, making sure they make it into browsers in a timely fashion.

Why you should contribute, too

Now, chances are that if you're reading this, you're also relying on the web platform for your job in one way or another. Which means that there's a chance that it also makes sense for your organization to contribute to the web platform. Let’s explore the reasons:

1. Make sure work is done on features you care about

If you're like me, you love the web platform and the reach it provides you, but you're not necessarily happy with all of it. The web is great, but not perfect. Since browsers and web standards are no longer black boxes, you can help change that.

You can work on standards and browsers to change them to include your use-case. That's immense power at your fingertips: put in the work and the platform evolves for all the billions of users out there.

And you don’t have to wait years before new features can be used in production like with yesteryear's browser changes. With today’s browser update rates and progressive enhancement, you’ll probably be able to use changes in production within a few months.

2. Gain expertise that can help you do your job better

Knowing browser internals better can also give you superpowers in other parts of your job. Whenever questions about browser behavior arrive, you can take a peek into the source code and have concrete answers rather than speculation.

Keeping track of standards discussions give you visibility into new browser APIs that are coming along, so that you can opt to use those rather than settle for sub-optimal alternatives that are currently available.

3. Grow as an engineer

Working on browsers teaches you a lot about how things work under the surface and enables you to understand the internals of modern browsers, which are extremely complex machines. Further, this work allows you to get code reviews from the world's leading experts on these subjects. What better way to grow than to interact with the experts?

4. It's a fun and welcoming community

Contributing to the web platform has been a great experience for me. Working with the Chromium project, in particular, is always great fun. The project is Google backed, but there are many external contributors and the majority of work and decisions are being done in the open. The people I've worked with are super friendly and happy to help. All in all, it's really fun!

Join us

The web needs more people working on it, and working on the web platform can be extremely beneficial to you, your career and your business.

If you're interested in getting started with web standards, the Discourse instance of the web Platform Incubator Community Group (or WICG for short) is where it's at (disclaimer: I'm co-chairing that group). For getting started with Chromium development, this is the post for you.

And most important, don't be afraid to ask the community. People on blink-dev and IRC are super friendly and will be happy to point you in the right direction.

So come on over and join the good cause. We'll be happy to have you!

By Yoav Weiss, Chromium contributor

Blink: A rendering engine for the Chromium project

Cross-posted from the Chromium Blog

WebKit is a lightweight yet powerful rendering engine that emerged out of KHTML in 2001. Its flexibility, performance and thoughtful design made it the obvious choice for Chromium's rendering engine back when we started. Thanks to the hard work by all in the community, WebKit has thrived and kept pace with the web platform’s growing capabilities since then.

However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit.

This was not an easy decision. We know that the introduction of a new rendering engine can have significant implications for the web. Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem.

In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat. Over the long term a healthier codebase leads to more stability and fewer bugs.

Throughout this transition, we’ll collaborate closely with other browser vendors to move the web forward and preserve the compatibility that made it a successful ecosystem. In that spirit, we’ve set strong guidelines for new features that emphasize standards, interoperability, conformance testing and transparency.

To learn more about Blink visit our project page.

By Adam Barth, Software Engineer

Celebrating Dart’s birthday with the first release of the Dart SDK

Working with a combination of small scripts to create large web apps is no easy task.  This is why a year ago we released a technology preview of Dart, a project that includes a modern language, libraries and tools for building complex web applications. Today, after plowing through thousands of bug reports and feature requests from the web community, a new, more stable and comprehensive version of Dart is now available and ready to use.


Dart is carefully designed so that you can build your web apps without having to choose between static and dynamic languages. With Dart, you can start coding simple scripts on your own and scale seamlessly to building large apps with hundreds of thousands of lines of code.  These complex apps can also be supported by a big team with a significantly reduced debugging and maintenance overhead.

With this first developer-oriented version of the Dart SDK, we’ve made several improvements and added many features:

• A faster Dart Virtual Machine that outperforms even V8 on some Octane tests.
• A new Dart to JavaScript translator that generates fast and compact output.
• An HTML library that works transparently on modern browsers.
• A library to interoperate with JavaScript code.
• An easy to use editor.
• Pub, a new package manager
• Dartium, a Chromium build with native Dart support.
• A server-side I/O library.
• A language specification describing the Dart semantics, including new features.

Over the following months, we will continue to work hard to evolve the SDK, improve Dart’s robustness and performance, and fine-tune the language while maintaining backwards compatibility.

You can download the Dart Editor from dartlang.org. It comes with a copy of the open-source SDK and Dartium. Thanks again for all your feedback - keep it coming.

Posted by Lars Bak, Software Engineer

Test your Web Apps on Chrome with ChromeDriver

ChromeDriver is a tool for testing websites with Google Chrome that implements the open source WebDriver wire protocol so it can easily be integrated with an existing WebDriver test suite. For those who aren't familiar with WebDriver, you may want to refer to our initial post about the project. Simply put, WebDriver presents an object-based API for automating the web from a real users perspective, such as clicking elements on a page and typing into text fields.

The WebDriver API is available for many popular browsers.  Each browser has its own driver, with ChromeDriver, of course, supporting the WebDriver API for Google Chrome. Unlike other drivers which are maintained by the open source Selenium/WebDriver team, ChromeDriver is developed by Chromium, the open source project that Google Chrome is based on.

Besides a new ChromeDriver release this past week, we wanted to share info about a new website dedicated to the project: http://code.google.com/p/chromedriver. This site will serve as the central location for all things relating to ChromeDriver. You can use the new site to:

• Download ChromeDriver
• Find information on getting started with and using ChromeDriver
• Submit ChromeDriver-specific bugs and feature requests

ChromeDriver works with the current stable, beta, and dev versions of Google Chrome. Older versions of Google Chrome are not supported and are not guaranteed to be compatible with ChromeDriver.  Consult the release wiki for more information on our release and support policy.

Thanks for testing with Google Chrome!

By Ken Kania, Chromium Developer

Chrome enables open innovation

Earlier this week, Google announced that Chrome’s HTML5 <video> support will change to match codecs supported by the open source Chromium project. Chrome will support the WebM (VP8) and Theora video codecs, and support for the H.264 codec will be removed so that resources can be directed completely towards open codec technologies. This is in line with Google’s continued support of the open web.

For more information, check out the original post.

By Ellen Ko, Open Source Team

Changing the Look of the Web with Stylebot

Stylebot editing the Open Source Blog in advanced mode

Stylebot editing the Open Source Blog in basic mode

Cascading Style Sheets (CSS) are a part of every web designer’s vocabulary when styling websites, and since its inception, the C (Cascading) in CSS was intended as a way to empower users to have the final say over how they perceive content on the web. But because creating user stylesheets generally requires programming, end users have not always been able to easily leverage this functionality. Stylebot, a new Google Chrome extension created as a Google Summer of Code project, hopes to finally unlock the power of the C in CSS by giving the end user final control on how web content is displayed.

At Google, the Accessibility Engineering team is very excited about the potential of extensions like Stylebot to improve the accessibility of the web, making it possible for users to customize the web to fit their needs. For example, a Stylebot user with special reading needs might change a webpage by removing images, picking new text and background colors, and even moving blocks of text around. And Stylebot saves the custom style they create, so the next time they access that page the changes will still be there. Even better, they can sync their saved styles across computers so that webpage will always appear with their preferred style.

We invited Ankit Ahuja, the Google Summer of Code student who worked on Stylebot, to write about his experiences creating the extension. While there’s still a lot of work to be done to make Chromium more accessible, extensions like Stylebot are a great step - giving users themselves the power to shape the way they interact with the web.

My name is Ankit Ahuja, and I successfully completed my Google Summer of Code project this year for Chromium. I was mentored by Rachel Shearer. My project is Stylebot, a Chromium extension that enables users to easily customize the web’s appearance. Ultimately, Stylebot aims to make the web more accessible and adaptable.

StyleBot screencast demo

One of the main objectives of the project was to allow users unfamiliar with CSS to be able to use this extension with ease. In the Basic mode, users launch Stylebot on a page, select an element and style it. Changes made by the users are automatically saved, so the next time they visit the page, their custom styles are already applied. This mode provides an easy-to-use GUI for the commonly used CSS properties. For the more advanced users, there is a separate mode in which they can write their own CSS.

A nontrivial problem was allowing the users to preview the changes instantly. So although a stylesheet is used to apply the custom CSS when the page is initially loaded, inline CSS is deployed while the user is in editing mode for a smooth, dynamic editing experience. Another important issue was determining the best way to position the Stylebot panel on the page. During testing, I found drag-and-drop to be slow. Instead, allowing the panel to be moved to a fixed left or right position felt the most user friendly. CSS parsing was required and luckily there already existed a CSS parser in JavaScript.

On my part, I’ve tried to make sure the Stylebot code is useful for other developers. I’ve kept the implementation of features like extension data synchronization, selection of elements, CSS selector generation, etc. separate, so that anyone can reuse the code easily. I’ve also used code from other open source projects. For example, the user interface is the CSS version of Cappuccino’s Aristo and the selection of elements is similar to Firebug’s implementation.

Take a look at a few examples we created using Stylebot. You can install the extension from the Google Chrome extensions gallery. We’re already receiving some positive and critical feedback, which is exciting!

I had an amazing experience participating in Google Summer of Code this year. I had a great time interacting with my mentor through the summer, who was very helpful and motivating. Finally, I would like to thank Google for sponsoring and making this project possible.

By Ankit Ahuja, 2010 Google Summer of Code Student and Rachel Shearer, Google Accessibility Engineering Team

Google Chrome’s RLZ library is now open source!

Today on the Chromium blog, we announced that we’re open-sourcing the RLZ library in Google Chrome as its own project. The RLZ library gives us the ability to accurately measure the success of marketing promotions and distribution partnerships in order to meet our contractual and financial obligations. For example, the RLZ library generates a query parameter that sometimes appears in Google search URLs in distributed products:


We’re excited to not only improve the transparency of Google Chrome, but also offer potentially useful code to the open source community. Please check it out and let us know what you think!

By Glenn Wilson, Product Manager

Chromium OS Now Open Sourced

In July we announced that we were working on a project called Google Chrome OS, an open source operating system based on the Google Chrome browser and built for today's web. For the past few months we have been working hard on developing a solid foundation and today we are excited to announce the Chromium OS open source project.

You can read more about our open source announcement at the Chromium Blog, or get involved directly at chromium.org. We look forward to working with the open source community to help shape the future of personal computing.

By Martin Bligh, Software Engineer