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.
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
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.
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 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 😉
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 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_​tree_​view_​column_​get_​cell_​data_​hint() that returns GTK_​TREE_​CELL_​DATA_​HINT_​KEY_​FOCUS, GTK_​TREE_​CELL_​DATA_​HINT_​SENSITIVITY or GTK_​TREE_​CELL_​DATA_​HINT_​ALL. 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.
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; \
mv $@.tmp $@; \
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.
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.