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

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 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.

Over the last few months, our browser team at Nuanti Ltd. has been developing Meta, a brand new WebKit port suited to embedding in OpenGL and 3D applications. The work is being driven by Linden Lab, who are eagerly investigating WebKit for use in Second Life.

While producing Meta we’ve paid great attention to resolving the technical and practical limitations encountered with other web content engines.

uBrowser running with the WebKit Meta engine

High performance, low resource usage

Meta is built around WebKit, the same engine used in web browsers like Safari and Epiphany, and features some of the fastest content rendering around as well as nippy JavaScript execution with the state of the art SquirrelFish VM. The JavaScript SDK is available independently of the web renderer for sandboxed client-side game scripting and automation.

It’s also highly scalable. Some applications may need only a single browser context but virtual worlds often need to support hundreds of web views or more, each with active content. To optimize for this use case, we’ve cut down resource usage to an absolute minimum and tuned performance across the board.

Stable, easy to use cross-platform SDK

Meta features a single, rock-solid API that works identically on all supported platforms including Windows, OS X and Linux. The SDK is tailored specifically to embedding and allows tight integration (shared main loop or operation in a separate rendering thread, for example) and hooks to permit seamless visual integration and extension. There is no global setup or initialization and the number of views can be adjusted dynamically to meet resource constraints.

Minimal dependencies

Meta doesn’t need to use a conventional UI toolkit and doesn’t need any access to the underlying windowing system or the user’s filesystem to do its job, so we’ve done away with these concepts almost entirely. It adds only a few megabytes to the overall redistributable application’s installed footprint and won’t interfere with any pre-installed web browsers on the user’s machine.

Open Source, no licensing fees

In the short term, we’ll be maintaining Meta in a public branch and putting out SDK builds, demo applications and developer documentation. Nuanti will be offering commercial and community support and is anticipating involvement from the gaming industry and homebrew programmers.

In the mid term, we’ll submit Meta as an official component of the WebKit Open Source project, where our developers are already actively involved in maintaining various subsystems.

Find out more

Today we’re launching meta.nuanti.com and two mailing lists to get developers talking. We’re looking to make this site a focal point for embedders, choc-full of technical details, code samples and other resources.

Epiphany using WebKit r32284

We also recently announced our plans to align more closely with the GNOME desktop and mobile platform. To this end we’re making a few technology and organisational changes that I hope to discuss in an upcoming post.

• GNOME ideas
  • Epiphany
    • Desktop integration
    • Bookmark and history integration
    • JavaScript debugger based on Drosera / Web Inspector
  • Evolution
    • Bug tracking aid
  • Empathy
    • WebKit Adium theme support
  • Desktop widgets
  • Integrated web app launcher
• WebKit ideas
  • Cairo SVG backend completion
  • GTK+ port test suite completion
• Mono ideas
  • WebKit-based HTML editor

If in doubt, now’s the time to submit proposals. Already-listed ideas are the most likely to get mentored but students are free to propose their own ideas as well. Proposals for incremental improvements will tend to be favoured over ideas for completely new applications, but a proof of concept and/or roadmap can help when submitting plans for larger projects.

Update: There’s no need to keep asking about the status of an application on IRC/private mail etc. It’s a busy time for the upstream developers but they’ll get back in touch as soon as possible.

Epiphany using WebKit r31371

There is actually still a little work to be done before we can claim a flawless Acid3 pass. Two of the most visible remaining issues in the GTK+ port are :visited (causing the “LINKTEST FAILED” notice in the screenshot) and the lack of CSS text shadow support in the Cairo/text backend which is needed to match the reference rendering.

It’s amazing to see how far we’ve come in the last few months, and great to see the WebKit GTK+ team now playing an active role in the direction of WebCore as WebKit continues to build momentum amongst developers.

Update: We now also match the reference rendering.

If you happen to be going, drop by on my WebKit Mobile presentation, 14:00 Room 01 this Monday. We have a small surprise waiting for Maemo developers.

Until I get round to writing things up, I refer you to Emmannuele’s posts. He summarises some of the graphics topics that came up and I would echo his sentiments about what a well organised, fun and dynamic event this was.

View slides (PDF format)

Demo sources

• Hosting a Dashboard widget
  • Simple example without JS integration

(Will update this post with more demo code over the next few days.)

Citations

• Slide 20:  All the cool kids are doing it (February 3rd, 2008) — donscorgie.livejournal.com
  
• Slide 30: WebKit and XULRunner (Mozilla) side by side on the XO (August 2nd, 2007) — j5live.com
• Slide 32: WebKit testing methodology for reproducible mobile benchmark performance results
• WebKit/GTK+ build instructions

“WebKit/GTK+ is a brand new port of the WebKit content engine providing standards compliance, high performance and seamless integration with the GTK+ stack. I’ll be demonstrating some of the latest features and taking a look at the ways developers can adopt the WebView API and apply HTML5, CSS, SVG, canvas and AJAX to create location-aware hybrid Web/GTK+ rich internet applications.”

Update: You can now get the slides from the talk.

What?

The talk will be short and light (only a 1/2 hour session) but I’ll be around all weekend so feel free to touch base if you have more questions or ideas. This session will target:

• GTK+ developers
• Web designers
• Anyone looking to deploy online and offline Web applications
  • on the desktop
  • on mobile devices

When?

11:15 - 12:15, Sunday, February 24, 2008

Where?

FOSDEM GNOME/Cross-desktop Developer Room, H.1301

This is the “native Windows port” a lot of people have been waiting for (though it’s technically no more or less native than Safari’s WebKit).

The taxonomy of the new port places it very close to Apple’s WebKit for Windows, which will remain the default build configuration. Both share the same foundation libraries, networking stack and build system.

The only difference is that the proprietary, non-redistributable CoreGraphics has been conditionally replaced (#16979) with the Cairo-based graphics backend developed and maintained by the WebKit GTK+ team. This conveniently lets us maintain the new code as an officially supported sub-port of WebKit without much additional infrastructure.

The result will be a WebKit Windows build that’s open and freely re-distributable for use in Open Source and proprietary/commercial applications (as long as any modifications to WebKit are made available), not just Safari.

This serves as validation of WebKit’s new porting layer, the modularity of the Windows port (Adam Roben and the Win team, you rock!) and the Cairo graphics backend.

Some technical details:

• Provides C++ and COM APIs including a full COM DOM binding. The interfaces aren’t yet final and are expected change.
• The Cairo backend will be used for on-screen rendering as well as printing, including native PDF output.
• Cairo is used for rendering all content including HTML, canvas and SVG.
• Will continue to use Apple’s Open Source CF and CFNetwork libraries for other functionality.
• The CF/CFNetwork libraries will need to be re-built from the available APSL 2.0 source releases. There may be small differences from the Safari binaries that need to be taken into account.
• Still needs work on basics like text rendering and build system integration. Patches welcome. Nothing available for end users yet.

For WebKit/GTK+ fans, the good news is that this work should help bring more developers and testers to the shared Cairo graphics backend. Everyone wins!