gtk

A web browser for the Raspberry Pi

As I previously mentioned, Collabora has been working with the Raspberry Pi Foundation on various projects including a web browser optimised for the Raspberry Pi.
Since the first beta release we have made huge improvements; now the browser is more responsive, it’s faster, and videos work much better (the first beta could play 640×360 videos at 0.5fps, now we can play 25fps 1280×720 videos smoothly). Some web sites are still a bit slow (if they are heavy on the JavaScript side), but there’s not much we can do for web sites that, even on my laptop with an Intel Core i7, use 100% of one of the cores for more than ten seconds!

The browser is based on Gnome Web (Epiphany) using WebKit 1 (i.e. the non-multi-process version of WebKit).

Our main achievements are:

  • More responsive UI and scrolling, even under heavy load (like when loading a page)
  • Progressive tiled rendering for smoother scrolling (as mobile browsers do)
  • Startup is three times faster
  • Avoid useless image format conversions
  • Better YouTube support, including on-demand load of embedded YouTube videos to make page load much faster
  • Hardware decoding of videos (through gst-omx)
  • Hardware scaling of videos (again, through gst-omx)
  • Reduction of the number of memory copies to play videos
  • Faster fullscreen playback using dispmanx directly (a bit buggy at the moment, we are working on it)
  • Memory and CPU friendly tab management
  • JavaScript JIT fixes for ARMv6
  • Disk image cache (decoded images are kept in memory mapped files in a cache, saving CPU)
  • Memory pressure handler support


The Raspberry Pi web browser (mp4 video file)

To install the browser, just update your Raspbian and install the “epiphany-browser” package:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install epiphany-browser

Thanks to all the people at Collabora that, at some point or another, helped on this project: Julien Isorce, Emanuele Aina, ChangSeok Oh, Tomeu Vizoso, Pekka Paalanen, André Moreira Magalhaes, Derek Foreman, Gustavo Noronha, Danilo Cesar, Emilio Pozuelo Monfort and Jonny Lamb (I hope I haven’t forgotten anybody!).
Also thanks to the Raspberry Pi Foundation, and in particular to Eben Upton, for their commitment to making browsing on the Pi better, and to Ben Avison for his work on optimising pixman and libav for ARMv6.

Update: people have reported a few bugs since the release, in particular a problem with Raspbian configured to use 24-bit or 32-bit mode for graphics. We should be able to fix this in a week or so.
Another problem is that Vimeo videos stopped working. This seems to be due to a change made by Vimeo that broke playback also on other browsers and on Android.

Maynard: a Wayland desktop shell for the Raspberry Pi

In the last year or so, Collabora has been working with the Raspberry Pi Foundation on a web browser and on Wayland. See Daniel’s and Pekka’s blog posts about their Wayland work.

To make Wayland on the Raspberry Pi actually usable, we needed a shell, but lightweight desktop environments (like LXDE) don’t support Wayland and normal desktops (like Gnome and KDE) are just too heavy.
This meant we ended up writing our own shell based on Tiago Vignatti’s gtk-shell, so Maynard was born!


Maynard running on my laptop (webm video file)


Maynard running on a Pi (mp4 video file)

Maynard is far from complete, but it’s already starting to take shape nicely. Its goals are to be functional, light and pretty, so it will never see some of the features one might expect from Gnome or KDE for instance.

The main current limitations are:

  • No XWayland support, so non-Wayland applications cannot run (issue #1).
  • GTK applications take too long to start (issue #2).
  • Active apps are not shown in the panel (issue #3).
  • No configurability (issue #7). I hope you like the background from kdewallpapers we use as you cannot change it for now 😉

Interested in the project? Follow these links:

GTK surprises on Maemo

Sometimes the creation of the contact chooser used on the N900 can be slow so, using callgrind and kcachegrind, I tried to understand what is the source of the slowness. This lead me to find some unexpected, and apparently undocumented, differences between upstream GTK and the Maemo version.

The Maemo 5 contact chooser
The Maemo 5 contact chooser

The widget contains a GtkTreeView that uses a model with just one column for the contact objects. How can its creation be so slow? To my surprise most of the time was spent decompressing the avatar images!
The avatars of the contacts are loaded, scaled and cropped in the cell data function of the GtkTreeViewColumn as, for various reasons, we cannot cache on disk the resulting image or generate it before the creation of the widget. Following calls of the cell data function for the same row won’t need to generate the avatar anymore. Doing non-trivial operations in the cell data function is not the nicest thing to do, but this should not be a problem as the cell data function is called only for the visible rows, right? No, at least not on Maemo!
To verify it just try this example program: on Maemo the cell_func() function is called once per item in the model plus once per visible item, elsewhere only once per visible item.

After a bit of investigation together with Claudio, we discovered that on Maemo there is a function called gtk_&#8203tree_&#8203view_&#8203column_&#8203get_&#8203cell_&#8203data_&#8203hint() that returns GTK_&#8203TREE_&#8203CELL_&#8203DATA_&#8203HINT_&#8203KEY_&#8203FOCUS, GTK_&#8203TREE_&#8203CELL_&#8203DATA_&#8203HINT_&#8203SENSITIVITY or GTK_&#8203TREE_&#8203CELL_&#8203DATA_&#8203HINT_&#8203ALL. The hint tells you why the function was called; in the example code the function is called on the hidden rows only to get their sensitivity so there is no need to set the “pixbuf” property of the cell at this point.

Just this tiny change in the address book code makes the contact chooser open much faster if you have a lot of contacts with big avatars, like the ones that Hermes creates. On the other hand the delayed loading made the scrolling become non-smooth :(
To fix the scrolling I had to implement some asynchronous loading of the avatars. The contact chooser now tries to load as many avatars as possible in idle moments and also tries to load first the avatars for the contacts that the user is more likely to see. The results seem quite good; now the contact list is fast, scrolling is smooth and the delayed loading of avatars should not be visible in normal cases.

Automatic generation of .list files

When you use a VCS that makes it easy to manage several braches, it’s easy to get conflicts in the .list file used to generate the C marshallers. I recently fixed this problem in WebKit stealing some code used at least by various Telepathy components and by avahi-gobject, and I want to share the solution so every project can benefit from it.

First of all you have to open your Makefile.am and move the myproject-marshal.list file from EXTRA_DIST to BUILT_SOURCES and add somewhere in the file:

myproject-marshal.list: $(myproject_SOURCES) Makefile.am
        ( cd $(srcdir) && \
        sed -n -e 's/.*myproject_marshal_([[:upper:][:digit:]]*__[[:upper:][:digit:]_]*).*/1/p' \
        $(myproject_SOURCES) ) \
        | sed -e 's/__/:/' -e 'y/_/,/' | sort -u > $@.tmp
        if cmp -s $@.tmp $@; then \
                rm $@.tmp; \
        else \
                mv $@.tmp $@; \
        fi

Then remember to remove the myproject-marshal.list file from your VCS (svn/git/hg/bzr rm).

The code will search for all the functions looking like myproject_marshal_RETTYPE__ARG1TYPE_ARG2TYPE and generate the myproject-marshal.list from them, regenerating automatically the list when you change a signal signature.

Update: fixed the blackslashes in the code that were misteriously eaten by WordPress.

Gnome 3.0 != Topaz

What the release team just announced sounds like a good plan for Gnome 3.0 and also a good strategy for other future major releases. Kudos to them and to the GTK+ developers!
I’m sure that they will give us more details soon both on the planet and on the relevant mailing lists.

Hurray for Gnome 3.0!