Skia graphics library in Chrome: First impressions
With the release of the WebKit-based Chrome browser, Google also introduced a handful of new backends for the browser engine including a new HTTP stack and the Skia graphics library. Google’s Android WebKit code drops have previously featured Skia for rendering, though this is the first time the sources have been made freely available. The code is apparently derived from Google’s 2005 acquisition of North Carolina-based software firm Skia and is now provided under the Open Source Apache License 2.0.
Weighing in at some 80,000 lines of code (to Cairo’s 90,000 as a ballpark reference) and written in C++, some of the differentiating features include:
- Optimised software-based rasteriser (module sgl/)
- Optional GL-based acceleration of certain graphics operations including shader support and textures (module gl/)
- Animation capabilities (module animator/)
- Some built-in SVG support (module (svg/)
- Built-in image decoders: PNG, JPEG, GIF, BMP, WBMP, ICO (modules images/)
- Text capabilities (no built-in support for complex scripts)
- Some awareness of higher-level UI toolkit constructs (platform windows, platform events): Mac, Unix (sic. X11, incomplete), Windows, wxwidgets
- Performace features
- Copy-on-write for images and certain other data types
- Extensive use of the stack, both internally and for API consumers to avoid needless allocations and memory fragmentation
- Thread-safety to enable parallelisation
The library is portable and has (optional) platform-specific backends:
- Fonts: Android / Ascender, FreeType, Windows (GDI)
- Threading: pthread, Windows
- XML: expat, tinyxml
- Android shared memory (ashmem) for inter-process image data references
Skia Hello World
In this simple example we draw a few rectangles to a memory-based image buffer. This also demonstrates how one might integrate with the platform graphics system to get something on screen, though in this case we’re using Cairo to save the resulting image to disk:
#include "SkBitmap.h" #include "SkDevice.h" #include "SkPaint.h" #include "SkRect.h" #include <cairo.h> int main() { SkBitmap bitmap; bitmap.setConfig(SkBitmap::kARGB_8888_Config, 100, 100); bitmap.allocPixels(); SkDevice device(bitmap); SkCanvas canvas(&device); SkPaint paint; SkRect r; paint.setARGB(255, 255, 255, 255); r.set(10, 10, 20, 20); canvas.drawRect(r, paint); paint.setARGB(255, 255, 0, 0); r.offset(5, 5); canvas.drawRect(r, paint); paint.setARGB(255, 0, 0, 255); r.offset(5, 5); canvas.drawRect(r, paint); { SkAutoLockPixels image_lock(bitmap); cairo_surface_t* surface = cairo_image_surface_create_for_data( (unsigned char*)bitmap.getPixels(), CAIRO_FORMAT_ARGB32, bitmap.width(), bitmap.height(), bitmap.rowBytes()); cairo_surface_write_to_png(surface, "snapshot.png"); cairo_surface_destroy(surface); } return 0; } |
You can build this example for yourself linking statically to the libskia.a object file generated during the Chrome build process on Linux.
Not just for Google Chrome
The Skia backend in WebKit, the first parts of which are already hitting SVN (r35852, r36074) isn’t limited to use in the Chrome/Windows configuration and some work has already been done to get it up and running on Linux/GTK+ as part of the ongoing porting effort.
Skia is licensed under Apache License v2. This is important to note because that makes it incompatible with GPLv2 unlike the 3 clause BSD.
OpenGL. Sounds promising (i think compiz and games — but i’m just layman). So where can Webkit/GNOME go with this hypothetically? What does this mean in terms of web usage? Gorgeous smooth scroll or webpage zooming, perhaps?
Hub: Thanks, I’ve updated the introduction replacing “BSD-style” with a link to the Apache license for accuracy.
The confusion arose from the BSD-style ‘LICENSE’ file in the toplevel directory that apparently covers only Chrome itself and not other sources in that directory.
Thanks for the good summary. Can you perhaps comment on how Skia compares to Cairo? At first glance they seem to overlap quite a bit, so I guess I’m missing something.
[…] Toker has blogged a little more in-depth about “Skia graphics library in Chrome: First impressions” with some interesting insights along with some […]
I’m a bit disappointed, and frustrated, that rather than use Cairo (which is available on all platforms nowadays), Google went out and invented another renderer. Why didn’t they just improve the already free and ubiquitous Cairo?
Craig,
I believe it was a direct result of Android WebKit having already adopted Skia. The expertise had developed in-house and I imagine there was little desire within Google’s browser teams to target two separate graphics backends. This is fair enough really, as having multiple backends is one of the best ways of producing comparative benchmarks and tuning each of the implementations. The Cairo and Skia backends are both used by multiple ports — great for validation.
This looks pretty promising. I can’t wait to see what you can do with it, Alp!
I’m confused about the term shader in your post when you mention OpenGL. It doesn’t seem to support OpenGL shaders as such from a quick glance of the code in gl/, but instead it looks like it renders normally the results of an SkShader (~ the image/colour/gradient source to draw with) to a texture and caches those.
Bob,
You’re right on SkShader. This was a quick-and-dirty first review pretty much on the same day the code drop for Skia came out (or caught my attention). Will update the post with an erratum.
Thanks for this summary. Your link to the svg folder is wrong.
[…] Toker, one of those graphics heavy hitters, has woken up to give us a nice summary about the ’skia’ graphics library which Google uses for the Chrome browser. I like that […]
[…] engine, SquirrelFish, Mobile Safari and the WebKit nightlies are including V8 along with the Skia graphics library. Both are already making their way into the main WebKit repository. What does this mean for Mac and […]
What about the new HTTP stack that you mentioned? I did a quick Google search but didn’t see anybody else talking about it.
Interesting that Google chose to write a new stack: what makes it better than the existing one(s)?
[…] used in Mobile Safari and the WebKit nightlies. Still, the code base for V8 along with the Skia graphics library are making their way into the main WebKit repository. The Skia graphics library may already be in […]
Hey,
Thanks for the short review. Indeed they use a lot of stack-allocated objects. A luxury a public stable library can’t afford… But then again, I’m yet to see its benefits. When we have someone like Chris Wilson looking after our memory allocations, I wouldn’t worry much…
Cheers,
behdad
[…] >>> Обзор библиотеки Skia […]
[…] used in Mobile Safari and the WebKit nightlies. Still, the code base for V8 along with the Skia graphics library are making their way into the main WebKit repository. The Skia graphics library may already be in […]
[…] But because it’s offered under the liberal BSD open source license, other bowsers can leverage Chrome bits (like the fast V8 JavaScript and Skia graphics engines or memory and security sandboxing) to gain […]
i thought that webkit-gtk was build on Cairo ?
see also Better Random Thoughts Than None At All, by vladimir
http://blog.vlad1.com/2008/09/09/better-random-thoughts-than-none-at-all/
antistress,
WebKit GTK+ is indeed built on Cairo. This was an investigation into the then newly-released Skia library and how it shapes up. We’re pretty firmly committed to Cairo, but it’s not actually too difficult to swap them around at build time for benchmarking or customisation.
how can i link to libskia.a? Sorry I don’t know how to compile it
[…] V8 che, per fare un altro esempio, la libreria grafica Skia di Chrome stanno già per entrare nel repository principale di WebKit. È solo questione di […]
The port directories you link to in Chromium src, such as skia/ports/ and webkit/port/platform/graphics/ , are gone. Where is the Linux back-end code these days? http://code.google.com/p/skia/source/browse/#svn/trunk/src/ports doesn’t seem to have code to open a framebuffer, just GL code.
It’s sad to see http://code.google.com/p/skia/wiki/Roadmap pining for SVG, PostScript, and PDF backends that are already implemented by Cairo, language bindings that are already available for Cairo, etc.
Anyway, thanks for your work!