[go: up one dir, main page]

For some time now, there’s been a lot of work going on to overhaul Chromium’s graphics system. New APIs and markup like WebGL and 3D CSS transforms are a major motivation for this work, but it also lets Chromium begin to take advantage of the GPU to speed up its entire drawing model, including many common 2D operations such as compositing and image scaling. As a lot of that work has been landing in tip-of-tree Chromium lately, we figured it was time for a primer.

At its core, this graphics work relies on a new process (yes, another one) called the GPU process. The GPU process accepts graphics commands from the renderer process and pushes them to OpenGL or Direct3D (via ANGLE). Normally, renderer processes wouldn’t be able to access these APIs, so the GPU process runs in a modified sandbox. Creating a specialized process like this allows Chromium’s sandbox to continue to contain as much as possbile: the renderer process is still unable to access the system’s graphics APIs, and the GPU process contains less logic.

With this basic piece of infrastructure, we’ve started accelerating some content in Chromium. A web page can naturally be divided into a number of more or less independent layers. Layers can contain text styled with CSS, images, videos, and WebGL or 2D canvases. Currently, most of the common layer contents, including text and images, are still rendered on the CPU and are simply handed off to the compositor for the final display. Other layers use the GPU to accelerate needed operations that touch a lot of pixels. Video layers, for example, can now do color conversion and scaling in a shader on the GPU. Finally, there are some layers that can be fully rendered on the GPU, such as those containing WebGL elements.

After these layers are rendered, there’s still a crucial last step to blend them all onto a single page as quickly as possible. Performing this last step on the CPU would have erased most of the performance gains achieved by accelerating individual layers, so Chromium now composites layers on the GPU when run with the --enable-accelerated-compositing flag.

If you’d like to read more about this work, take a look at this design doc which outlines Chromium’s accelerated compositing system. Over time, we’re looking into moving even more of the rendering from the CPU to the GPU to achieve impressive speedups.


Posted by Vangelis Kokkevis, Software Engineer

Foreword: When we released Google Chrome almost two years ago, we also released the source code under an open-source license. Just as Firefox, WebKit, and other open source projects helped to drive the web forward, we wanted to follow suit and ensure that others could use the code we developed to make their products better. The Chromium codebase provides a complete browser to build on, so that if you want to focus on one particular piece, such as drastically changing the user interface, you can do that without having to worry about how to get amazing performance in the rest of the browser.

Recently, Flock released a new beta version of their browser built on top of the Chromium codebase. For those of us in the Chromium project, this is extremely exciting and encouraging. We believe that users having a choice between multiple browsers is a great thing, as it spurs innovation and competition, and lets users choose a browser that provides the best experience for them. Flock brings an innovative approach to their "social web browser," and we are glad to welcome them into the Chromium community. As part of that, we wanted to offer the team behind Flock an opportunity to talk about the ideas behind Flock, how Chromium helped them in achieving their goals, and their vision for the future. What follows is a perspective from Clayton Stark, VP Engineering at Flock.

When Flock began developing its first web browser five years ago, "the social web" was a small, niche market. Today social is the mainstream web, and this evolution in the market drove our development roadmap. With the new Flock browser, our engineering team focused on designing a straightforward and integrated social dashboard that delivers an experience simple enough for a mass audience. This is where the technology behind Chromium came into the picture for Flock. As Chromium emerged, we saw that not only was there significant improvements to performance, but also apparent was a simple and elegant user interface and architecture across all the various systems.

A core goal of new Flock is to keep our users in touch with all of their friends and feeds with a minimum of configuration, and at the same time, make it fun and simple. With all of the users’ feeds and social activity streams flowing into the scrolling sidebar, we knew the performance had to be first-rate, and that techniques we used for earlier versions of Flock were unlikely to perform at scale. With Chromium under the hood, we were able to leverage web workers, and that, combined with the raw horsepower of V8, allowed us to scale the use of the sidebar to manage very large data sets (in the first few weeks after the beta launched we saw a few hundred million activities flowing into Flock’s sidebar). Most importantly, benchmark testing shows us that New Flock with Chromium performs in the top-tier of all browsers available in the market.

Clearly the web is evolving very quickly, and we are seeing more and more people discovering content through their friends. The Flock team is energized by the big developments coming fast in this emerging, interest-graph-enabled web, and we have a roadmap in front of us that we are really excited about. The browsing platform needs to continue to mature at a rapid pace to support the dramatic changes in online user behavior. And, as it does, we already see the performance and power in Chromium that we need to allow us to focus on the innovations we want to bring forward, on top of the platform.

So, I’d like to send out a huge thanks on behalf of the Flock team to all those who have contributed to the Chromium project. Your work has made our project possible, and made new Flock our best release ever.

Clayton Stark, VP Engineering
Flock, Inc.

Posted by Ian Fette, Product Manager
Labels:

Since we launched the Google Chrome extension system, one of the most frequent requests we’ve gotten is to add the ability to integrate with the context menu (the menu that pops up when you right-click on a link, image, or web page).


Now in Google Chrome Beta, developers can do just that. The new context menu API allows extension developers to register menu items for all pages or for a subset of pages. Developers can also register menu items for specific operations, like right-clicking on an image or movie. For example, you could create an extension that makes it easy for users to share interesting images from images.google.com with their friends on Google Buzz.

Some users have lots of extensions installed. To help these users avoid ending up with gigantic unwieldy context menus, Google Chrome automatically groups multiple menu items from the same extension into a sub-menu.


We’d also like to announce two new experimental APIs. These APIs aren’t quite ready for prime-time yet, but we’re really excited about them and couldn’t wait to get your feedback.
  • The omnibox API allows extension developers to integrate with the browser’s omnibox. With this API, you can build custom search support for your favorite website, keyboard macros to automate tasks, or even a chat client right into the omnibox.
  • The infobars API allows extension developers to display infobars across the top of a tab. These infobars are built using normal HTML, so they can be heavily customized and interactive.
For the complete list of new extension APIs in Google Chrome beta, see the docs. And let us know if you make something cool. If we like it, we’ll send you a free extensions hoodie and may even feature you in the gallery.

We look forward to seeing what you come up with!

Posted by Aaron Boodman, Software Engineer
Labels: ,

Since our announcement of the Chrome Web Store at Google I/O, our team has been hard at work preparing for our launch later this year. Today we’re making the first step towards this milestone by making available a developer preview of the Chrome Web Store.

Developers can now start uploading apps and experiment with packaging them, installing them in Chrome (using the latest Chrome dev channel) and integrating our payments and user authentication infrastructure.

To get started, take a look at our recently updated documentation for installable web apps, which explains how to prepare and package your apps. You should also review some additional documentation we just released on the store’s licensing and user authentication features.

To upload your app, you’ll need to use the upload flow of the Google Chrome Extensions Gallery .



When the Chrome Web Store launches, it will replace the current gallery, featuring a completely new design for users to discover great apps, extensions and themes all in one place. Until then, only you can see the apps you upload - they will not be visible to other visitors of the gallery during this developer preview. In the meantime, you can continue to use the gallery for publishing Chrome extensions and making them available to Chrome users.

We look forward to sharing more news about the store and its features over the next weeks. Meanwhile, we encourage you to subscribe to our developer discussion group for apps and look for updates on the Chromium blog.

Posted by Michael Noth, Software Engineer

Since we introduced extensions in Google Chrome, we focused on making the platform more robust, by continuously exposing new APIs to developers. This has helped our extensions gallery blossom where more than 6,000 extensions are listed today and more than 10 million extensions are downloaded by Chrome users every month.

We designed security into the extensions system from day 1 but we’re always looking for more ways to protect users. So, today, we are introducing two significant changes in the Google Chrome Extensions Gallery: a developer signup fee and a domain verification system.

The developer signup fee is a one-time payment of $5. It is intended to create better safeguards against fraudulent extensions in the gallery and limit the activity of malicious developer accounts. Starting today, this fee will be required to publish extensions, themes and soon apps in the gallery. We are waiving the fee for developers who already registered with the gallery (specifically before 11am PST today), so that they can continue to update their extensions and publish new items without paying the fee.

Domain verification is another addition that we believe will protect users and developers alike. Developers will be able to associate their extensions (and soon their apps) with domains they own or manage using Google’s Webmaster Tools. This way, they can clearly associate their extension with their brand and website, which in turn will help users identify “official” extensions in the gallery.



We believe that these are important improvements to the security of the gallery. We understand that changes like these can create a lot of questions, so please reach out to us on our developer discussion group for extensions.


Posted by Gregor Hochmuth, Product Manager

We think HTML5 will make your work more engaging and create a faster, more responsive experience for your users, so we're happy to add today a slew of new content to html5rocks.com.

If you want to not only get up to speed, but understand the browser differences and techniques for a robust implementation, please take a look through the new guides for implementing HTML5 video, understanding "offline," auditing your webapp with the Chrome developer tools, and using web workers and @font-face. You can now comment about your experiences with these features and stay up to date on new content via our new RSS feed.

We're also sharing the new HTML5 Studio, a collection of samples of these features in use, with code you can learn from and hack on.


If you'd like to contribute code, guides, or samples, please get in touch on the bug tracker or on @ChromiumDev. We'd love to incorporate your work.

Posted by Paul Irish, Google Chrome Developer Relations
Labels:

Since Google Chrome launched almost 2 years ago, the team has embraced the “launch early and often” strategy by releasing Dev channel builds almost weekly. But sometimes, such as when we’re in the process of moving a Dev channel release to the Beta channel, we’re unable to release a new Dev channel build, and other times, even a week is too long to wait to get feedback from the field on a change.

The team considered updating the Dev channel more frequently, but doing so would require us to forgo our manual testing pass on these builds. Even though the Dev channel is often rough around the edges, we realized that this lack of testing would result in a Dev channel that’s too unstable even for early adopters and developers. That’s why, a few days ago, we released a new experimental version of Google Chrome called Google Chrome Canary Build. We plan to update the Canary Build more frequently than the Dev channel, with riskier changes, and usually without a human being ever verifying that it works, so the Canary Build is only for users who want to help test Google Chrome and are comfortable using a highly unstable browser that will often break entirely. To enable you to continue using the same browser you love when the canary croaks, we’ve made it possible to install the Canary Build in addition to the Dev, Beta or Stable channel versions of Google Chrome.

The Canary Build is still brand new so it currently has a few limitations. Currently, it’s only available for Windows and cannot be set as your default browser. You can star the issues for Mac and Linux support, as well as the issue for default browser support to cast your vote and be notified of progress there.

If you like to live on the bleeding edge, give the Google Chrome Canary Build a shot and let us know what you think. The early feedback on crashes, performance regressions, broken features and other problems is incredibly valuable to us, so thanks!

Posted by Henry Bridge, Product Manager