WorryFree Computers   »   [go: up one dir, main page]

We’re happy to announce that WebGL is now on by default in Google Chrome’s beta channel, with some shiny new demos to show off what the technology can do.

WebGL is a 3D graphics API for JavaScript that developers can use to create fully 3D web apps. It is based on the OpenGL ES 2.0 API, which should be familiar to many 3D graphics developers. Google, Mozilla, Apple, Opera and graphics hardware vendors have been working together to standardize WebGL for over a year now, and since the spec is just about final at this point, we wanted to get our implementation out there for feedback.

While you may not find much WebGL content on the web, we expect developers to quickly create a lot of content given the power and familiarity of the API. To inspire developers and give users a taste of the kind of apps they can expect in the near future, we’ve worked with a few talented teams to build a few more 3D web apps:

Body Browser, a human anatomy explorer built by a team at Google as a 20% project



Nine Point Five, a 3D earthquake map by Dean McNamee



Music Visualizer, a jukebox that synchronizes 3D graphics to the beat of the music by Jacob Seidelin



You can find these and other demos in the new Chrome Experiments Gallery for WebGL demos. Now that WebGL is enabled in the beta channel, the Chrome Experiments team is looking for your cool WebGL app submissions to show off this slick technology, so don’t forget to submit your cool 3D apps!

Posted by Kenneth Russell, Software Engineer

Since we launched the Chromium project over two years ago, we’ve been hearing a lot of feedback from IT administrators who want to manage and configure Google Chrome. Of course, we were eager to do what we could to help them get Chrome deployed inside their organizations.

Today, after talking directly to administrators and testing the features extensively with other organizations, we believe the first set of features is ready for prime-time. Both Chrome and Chromium are now manageable through Group Policy objects on Windows, plist/MCX configuration on Mac, and special JSON configuration files on Linux. We polished up the NTLM and Kerberos protocol support, and created a list of supported policies and administrative templates to help administrators deploy. For users needing access to older web applications not yet qualified for Chrome, we also developed Chrome Frame, an Internet Explorer (TM) plug-in that provides Chrome-quality rendering for the broader Web, while defaulting to host rendering for any web applications that still require IE.

No feature is really useful to an administrator without great documentation, so we wrote articles to help admins in the configuration and deployment of both Google Chrome and Chromium. We also documented answers to the top questions testers encountered when deploying.

Even though the first set of features is done, we still have a lot more we’d like to do. We have some interesting ideas that we’re working on, including more policies to manage everything in the content settings and authentication protocols, and interesting new ways to deploy policy cross-platform. But we could use your help: please try out the new features by checking out the documentation, downloading the MSI installer, and filing bugs. And let your administrator know to give it a try and let us know what they think.

Posted by Glenn Wilson, Product Manager and Daniel Clifford, Software Engineer

Chrome Developer Tools' Scripts panel provides a graphical JavaScript debugger and allows you to set breakpoints in the JavaScript source code. However, setting breakpoints in the source code does not always work well, especially when the application is large and you are not familiar with the entire code base. To better support this use case, we are introducing a new set of breakpoints that allow you to break on UI and network events.

Suppose you need to find the piece of code that modifies a specific node in a document. Right-click on that node in the Elements panel and select the appropriate “Break on...” context menu option and you are all set. The debugger will pause JavaScript execution right before the node gets modified next time.



To learn more about DOM breakpoints and other new kinds of breakpoints, visit our Breakpoints Tutorial page.

Posted by Pavel Podivilov, Software Engineer
Labels:

It’s hard to believe, but it’s already been a full year since we launched the Google Chrome extensions gallery.

It’s been a busy twelve months:
  • The gallery has grown to over 8,500 extensions and 1,500 themes.
  • A third of Chrome users have at least one extension installed.
  • Over 70 million extensions and themes have been installed.
On the client side, we added features like:
Looking forward, we’re very excited about the Chrome Web Store, where developers will be able to easily sell their apps, extensions, and themes.

And we’re not going to slow down on the features, either. The next Chrome release will add API support for the omnibox and pinned tabs. Beyond that, we’re hard at work on popular requests like network interception and download management APIs, as well as new experimental APIs for sidebars and development tools.

Thanks for all your support over the last year, from bug reports to testing new APIs. It’s been a bit frantic at times, but mostly it’s been fun.

Posted by Aaron Boodman, Software Engineer
Labels:

Today we are introducing Crankshaft, a new compilation infrastructure for V8, Google Chrome’s JavaScript engine. By using aggressive optimizations, Crankshaft dramatically improves the performance of compute-intensive JavaScript applications - often by more than a factor of two! This will give users a faster and more responsive experience loading web pages and applications built with complex JavaScript. Here is a comparison of Chrome with and without Crankshaft on the V8 benchmark suite:


The benchmarks that benefit the most from Crankshaft are Richards, DeltaBlue and Crypto. This shows that we have taken the performance of JavaScript property accesses, arithmetic operations, tight loops, and function calls to the next level. Overall, Crankshaft boosts V8’s performance by 50% on the V8 benchmark suite. This is the biggest performance improvement since we launched Chrome in 2008.


In addition to improving peak performance as measured by the V8 benchmark suite, Crankshaft also improves the start-up time of web applications such as GMail. Our page cycler benchmarks show that Crankshaft improves the page load performance of Chrome by 12% for pages that contain significant amounts of JavaScript code.

Crankshaft uses adaptive compilation to improve both start-up time and peak performance. The idea is to heavily optimize code that is frequently executed and not waste time optimizing code that is not. Because of this, benchmarks that finish in just a few milliseconds, such as SunSpider, will show little improvement with Crankshaft. The more work an application does, the bigger the gains will be.

Crankshaft has four main components:
  1. A base compiler which is used for all code initially. The base compiler generates code quickly without heavy optimizations. Compilation with the base compiler is twice as fast as with the V8 compiler in Chrome 9 and generates 30% less code.
  2. A runtime profiler which monitors the running system and identifies hot code, i.e., code that we spend a significant amount of the time running.
  3. An optimizing compiler which recompiles and optimizes hot code identified by the runtime profiler. It uses static single assignment form to perform optimizations such as loop-invariant code motion, linear-scan register allocation and inlining. The optimization decisions are based on type information collected while running the code produced by the base compiler.
  4. Deoptimization support which allows the optimizing compiler to be optimistic in the assumptions it makes when generating code. With deoptimization support, it is possible to bail out to the code generated by the base compiler if the assumptions in the optimized code turn out to be too optimistic.
V8 with Crankshaft for the 32-bit Intel architecture is available today in the V8 bleeding edge repository and in canary builds of Chrome. Work on the ARM and 64-bit ports has started.

We are excited about the JavaScript speed improvements we are delivering with Crankshaft today. Crankshaft provides a great infrastructure for the next wave of JavaScript speed improvements in V8 and we will continue to push JavaScript performance to enable the next generation of web applications.

Kevin Millikin, Software Engineer and Florian Schneider, Software Engineer

Since this past March, we’ve been working closely with Adobe to allow Flash Player to take advantage of new sandboxing technology in Chrome, extending the work we’ve already done with sandboxing for HTML rendering and JavaScript execution. This week, we’re excited to roll out the initial Flash Player sandbox for our dev channel users on Windows XP, Vista and 7.

This initial Flash Player sandbox is an important milestone in making Chrome even safer. In particular, users of Windows XP will see a major security benefit, as Chrome is currently the only browser on the XP platform that runs Flash Player in a sandbox. This first iteration of Chrome’s Flash Player sandbox for all Windows platforms uses a modified version of Chrome’s existing sandbox technology that protects certain sensitive resources from being accessed by malicious code, while allowing applications to use less sensitive ones. This implementation is a significant first step in further reducing the potential attack surface of the browser and protecting users against common malware.

While we’ve laid a tremendous amount of groundwork in this initial sandbox, there’s still more work to be done. We’re working to improve protection against additional attack vectors, and will be using this initial effort to provide fully sandboxed implementations of the Flash Player on all platforms.

We’ll be posting updates as we continue working with Adobe to add new security improvements to the Flash Player sandbox. For those of you on the dev channel for Windows, you’ll be automatically updated soon, and we look forward to your feedback as you test it out. If you prefer to disable this initial sandbox in your Chrome dev experience, add --disable-flash-sandbox to the command line.

Posted by Justin Schuh and Carlos Pizano, Software Engineers