The Astonishing Progress Of Blink |
Written by Ian Elliot | |||
Wednesday, 09 April 2014 | |||
It is just over a year since Google broke away from WebKit and decided to create its own version of the rendering engine just for Chrome. What is amazing is just how much benefit Chrome has accrued from the change. Google forked WebKit to create Blink back in April 2013 and soon after Opera joined in. The pair have been working on the project for just over a year now and it seems to be paying off.
Google is claiming that the Blink community is as viable as the original WebKit project with 33% of the 200 contributors being non-Googlers. The driving force behind the spilt was that WebKit was suffering from having to be the rendering engine for more than one browser - most notably Apple's Safari and Google's Chrome. By creating Blink Google could simply dump all of the code that was needed to support other browsers and work on making a web page renderer that targeted just Chrome. A recent blog post celebrating Blinks first birthday suggests that the idea was a good one. The fact that Blink works in a Chromium environment and only a Chromium environment has allowed the team to reduce the code base by an amazing half. Yes half of the lines of the code were about supporting features not relevant to Chromium. To quote the blog: "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. " Ah a "C++ garbage collector" how many times will that have been implemented now? The WebIDL compiler is also interesting in that it has been moved from Perl to Python with the comment: "The new Python IDL compiler is much more readable and maintainable." There have also been improvements in efficiency: "For example, the tight relationship between Blink and Chromium has allowed us to improve the abstraction layer between Blink and 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. " In addition to cleaning up the code and making it less complex a number of new features have been added. Of course there is the problem of keeping up with all this change and the new Chromium Feature Dashboard provides a list of what is used and what isn't. The idea is that it can be used to target features that can be deprecated for further code savings and simplicity. What does the coming second year of Blink promise? "2014 promises an even greater increase in mobile computing, thus we continue to focus Blink’s efforts there. Software performance is critical on mobile devices because of constrained hardware and high user expectations. To improve mobile web performance, we have projects to speed up rendering, minimize binary size, reduce input latency, preserve battery power, shrink memory consumption, and more. " Despite the worries that Google may use Blink to separate Chrome from the rest of the browsers, and there is some evidence that this might happen by accident or design - see Google Removes CSS Regions From Blink - An Optimization Too Far, creating Blink seems to be paying off for Chrome. Browser Split - Google And Opera Fork WebKit To Blink
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
Comments
or email your comment to: comments@i-programmer.info
|
|||
Last Updated ( Wednesday, 09 April 2014 ) |