A graphics developer’s perspective on Blink

http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html

As a graphics developer, I think Blink is awesome because it means web developers can get much closer to The Metal™. Blink runs on one and only one graphics engine (“Skia”) which can be piped directly to developers.

First, some history on drawing pixels in WebKit:
WebKit runs on top of many graphics libraries: CoreGraphics, Cairo, OpenVG, QPainter, and Skia. These libraries take calls such as “drawRectangle” and actually change pixels on the screen. WebKit’s GraphicsContext interface is where these libraries come together (it’s not a coincidence that the HTML5 2d canvas context looks a lot like GraphicsContext!) The Metal™ for WebKit--the closest developers can get to basic drawing commands--is this lowest-common-denominator of 5 graphics libraries, some of which aren’t open source.

There are plenty of concrete examples of the pain this causes; lets pick on paths. Because GraphicsContext doesn’t provide an API for accessing individual path segments in O(1) time, developers cannot efficiently modify paths [1]. Because GraphicsContext doesn’t support hit testing on text, you won’t find APIs in SVG2 for it [2]. These are the restrictions of a lowest-common-denominator that affected 2 of the 4 largest browsers.

Blink removes the cruft and aligns on a single, fast, open-source stack. This is in addition to the multiple multi-core refactorings to speed up the main thread, scrolling changes, better high-DPI support, rewritten style resolver, etc. I think this is going to be great for the web.

[1] https://bugs.webkit.org/show_bug.cgi?id=105230#c7
[2] http://www.w3.org/2013/01/17-svg-minutes.html


http://my.opera.com/haavard/blog/2010/05/06/google-webkit
Animated Photo
Shared publiclyView activity