The changelog is not that impressive (no new features), but since the bug fixes include fixes for crashers, it’s definitely worth to upgrade to 1.1.

For those who don’t know, Pixman is a backend library shared by Cairo and X.org, which takes care of various basic 2D graphics operations when there isn’t any specific GPU support for them.  It gets pretty heavy use if you use the XRender protocol on a bare framebuffer, for example.  So optimising Pixman for the latest ARM developments will make Gecko faster, as well as any of those “fancy” compositing window managers which are all the rage these days.

Now the following operations are accelerated, all on RGB565 framebuffers (which may or may not be cached):

• Flat rectangular fills.  (These also work on other framebuffer formats.)
• Copying 16-bit images around.
• Converting 24-bit xRGB images (eg. a decoded JPEG) into the framebuffer format.
• Flat translucent rectangles.
• Compositing 32-bit ARGB images (eg. a decoded PNG).
• Glyphs and strings thereof (8-bit alpha masks, with an overall colour that might be translucent).

Most of the listed operations are now at least twice as fast as they were without NEON, and many come within spitting distance of available memory bandwidth on typical ARMv7 hardware.  Using a benchmark of common operations (as issued by a common Web browser visiting a popular news portal), we measured an overall doubling in performance, despite the most common drawing operations being extremely tiny and therefore difficult to optimise.

In some cases on a more synthetic benchmark, the throughput is vastly greater than that, at least when running on an uncached framebuffer (which tends to hurt generic code very badly).  The main performance techniques were to read from the framebuffer in big chunks (where required), preload source data into the cache, and then process data in decent-sized chunks per loop iteration.  This essentially removes the performance advantage of a “shadowed framebuffer”, so you can now sensibly save memory by turning it off.

We also found some opportunities for reducing per-request overhead in both Pixman and X.org.  Hopefully these improvements will also be integrated upstream in the near future.

And after furious few weeks of hacking I’m pleased to announce that the Browser D-Bus Bridge finally reached the goals set for the first official release. Unlike the usual cautious approach of releasing with low numbers, I decided to aim high and give the dreaded one-oh slate to the first release.

So what were the goals?

First and foremost the type support needed fixing, there was missing types (structs and variants) and inadequate support for nested complex types. Much hair pulling later, there should not be types that cannot be transferred through the Bridge (knock on wood, naturally every possible combination hasn’t been tested).

The most exciting new feature is the introspection support. Previously the API was defined in terms of creating individual methods and signals, but now you can simply point the Bridge to a service and say “I want this interface, ok?”. What you get is a JS object that already contains the method and signal objects so you can just set your callbacks and fire away.

For a release there needs to be serious documentation, and so now the dbus.js API wrapper is annotated with jsdoc comment blocks. Generated docs are available online (see the wiki page).

Naturally, also all sorts of silly leaks were plugged, but let’s not pay attention to those ;)

You can find the release tag in the git repository or if you prefer, download the 1.0 release tarball. The tarball includes generated documentation, which has few cosmetic changes over the release tag. It also includes a compilation fix to jscore tester utility not present in the tag. Sorry about that.

I followed the instructions and got it up’n'running in no time encountering nothing undocumented.

Some debug prints from the X.Org output:

PVR2D SGX EXA acceleration initialized
DRI2 initialized


I started with cairoperf and ran it using xf86-video-omapfb driver (no EXA) and then with Nokia’s EXA accelerated fbdev (yeah, they are using the old name).

The results were surprising: 13 relatively small speed ups and 585 relatively big slowdowns.

I also tested with mx11mark and the results were in line with cairoperf results: total score with x-v-o was 17 and with Nokia’s driver only 13.

I wouldn’t mind if somebody proved my tests wrong…

ALIP is designed to integrate a hardware specific BSP, including proprietary BSPs, with a generic Linux software stack  (e.g. GNOME Mobile) providing a straightforward way of creating a base for a new product. The UI and application layer is expected to be product specific and ALIP includes only a simple Matchbox based desktop environment.

The changes from the first release are listed thoroughly on the generic-2 release notes but here’s a list of the biggest changes:

• C library is now compiled for the target hardware instead of
  taking it from the Scratchbox’ toolchain as-is.
• example-project was renamed to alip-project.
• Official support for Beagle board.
• Reference BSPs for Beagle board and OMAP3 EVM
• Up-to-date software components (aligned with X.Org 7.4 and GMAE 2.24.3).
• Better support for 3rd party multimedia codecs.
• More meaningful component suites.
• X.Org driver with XV extension for OMAP based hardwares.

Kaze’s (similar to alip-project but using XFCE instead of Matchbox) master branch is already updated to match the new generic-2 release but it’s not branched for stable release yet.

Sources are available as tarballs and from git.

Just to be clear (this is a very common concern), it does *not* mean using D-Bus from web sites. The target audience for the Bridge is browser extension and UI developers, not web developers. Using web technologies (HTML, CSS, JavaScript…) to build applications is an increasingly interesting thing, and this is another step in that direction. Currently the Bridge only has API for clients, so you can’t (easily) implement a D-Bus service with it (yet).

The way we have approached this is to create a thin API to bind the basic functionality of D-Bus into JavaScript. This is to minimize the work needed in the actual browser-to-D-Bus bridging. This low-level API can then be used to wrap D-Bus services with JavaScript to give a comfortable end-user API.

There are two implementations of the Browser D-Bus Bridge, one for use in Gecko-based applications and one for WebKit-based applications. We have tried to use the most natural way for of integrating with the engine for both cases. For Gecko this means creating an XPCOM service and for WebKit an add-on library.

Currently the Bridge is lacking support for some of the more complex types and deeply nested message signatures, but it’s already usable for example controlling NetworkManager or querying HAL for the battery level. Future plans for the Bridge include (naturally) finishing the message args support, adding introspection support (this might be implemented just in the JavaScript side though) and later adding API for implementing services from JavaScript.

Good starting points for the Bridge are the wiki page and browsing the source code.

We don’t have a bugzilla or mailing list for the Bridge, but you can mail me at kalle.vahlman at movial.com and I’ll try to help in any way I can. Oh, and I’ll gladly integrate patches too ;)

I mainly followed the instructions on the omapzoom.org and on elinux.org. The JDK from my Debian Etch didn’t seem to work, so I had to download the JDK from sun.com and set up some environment variables. Once those were set the compilation succeeded without problems. I would have saved some hours if I had read the instructions properly in the first place.

The instructions were a bit vague on to do after the compilation was finished. Eventually I created the card.img that acts as a MMC/SD card and launched the emulator:


./out/host/linux-x86/bin/emulator -sdcard card.img -system out/target/product/ldp1/ -kernel ./prebuilt/android-arm/kernel/kernel-qemu


The emulator runs the real ARM root file system image with qemu so it fully matches the actual file system. The file system includes e.g. ssh so I could IRC with the terminal application but it doesn’t include e.g. cp, which seems a bit odd. The file system directory hierarchy looks completely weird and messy to me. It mounts a read only ramdisk as root and data, system and sdcard under it.

Android provides Android Debug Bridge (adb) that is capable of sending files to the root file system run by the emulator or giving you a remote shell, among other things. I used it to get more complete busybox there and tarred (no compression) the /data and /system directories to the fake MMC/SD card. If I had had a Linux setup that understands YAFFS file systems this would have been a bit easier since I could have used the original images directly without copying the content from the running emulator.

I set up an EXT3 root file system to a real SD card from the ramdisk, system and data tar balls and replaced the init.rc with init.omapldpboard.rc and booted the Zoom board with the uImage built separately according to the instructions.

The desktop (or home) is something new but the menus that open from the bottom actually seem quite traditional. The UI looks quite polished and is very responsive on the Zoom. Everything feels snappier than I would have expected. The Zoom doesn’t have WLAN and I didn’t find anything to set up the wired network with a quick search so I didn’t have a network connection.

I’m sure we’ll see interesting devices (in addition to G1) based on Android in the future.