GTK2 running on top of DirectFB on OpenWrt!

OpenWrt is now able to run applications based on toolkit GTK+ on top of DirectFB!

Using DirectFB avoids having a full blown X11-server (most times Xorg) running, but having the possibiliy of getting nice GTK2 widgets onto your display without altering applications which are using the toolkit.

I was quite happy I got that working, because unfortunately DirectFB-support on part of gtk2 is quite broken in most versions.

Due its incredible slowness of GTK2 on the Openmoko Freerunner (400 MHz ARM, 128 MB RAM) I didn’t expect much of gtk2 on top of DirectFB.

Surprisingly, a simple gtk2 app runs quite well and responsive on my Ben NanoNote by qi-hardware (366 MHz mips, 32 MB RAM).

I was curious and started some benchmarking with the gtk2 performance testing tool “gtkperf”. However I had to patch gtkperf that it’ll be usable with the qvga-resolution on the Ben NanoNote (otherwise parts of the app were hidden and the benchmark will get falsified because not the whole gets redrawed).

Do not compare your results of an original version of gtkperf with mine – varieties may be caused due to mentioned changes! (Patch: http://nanl.de/files/patches/gtkperf/gtkperf-adjust-layout.patch)

What got tested?

gtkperf using GTK2 on:

  1. Openmoko Freerunner with DirectFB
  2. Openmoko Freerunner with Xorg and glamo driver
  3. Openmoko Freerunner with Xorg and fbdev driver
  4. qi-hardware Ben NanoNote with DirectFB
  5. qi-hardware Ben NanoNote with Xorg and fbdev driver (not yet done)
1 2
GtkEntry – time: 0.91
GtkComboBox – time: 16.01
GtkComboBoxEntry – time: 10.18
GtkSpinButton – time: 2.37
GtkProgressBar – time: 1.04
GtkToggleButton – time: 2.54
GtkCheckButton – time: 1.72
GtkRadioButton – time: 4.16
GtkTextView – Add text – time: 9.47
GtkEntry – time: 2.08
GtkComboBox – time: 30.40
GtkComboBoxEntry – time: 21.65
GtkSpinButton – time: 3.54
GtkProgressBar – time: 2.55
GtkToggleButton – time: 4.66
GtkCheckButton – time: 2.71
GtkRadioButton – time: 6.64
GtkTextView – Add text – time: 26.06
3 4
GtkEntry – time: 1.73
GtkComboBox – time: 22.70
GtkComboBoxEntry – time: 16.52
GtkSpinButton – time: 2.60
GtkProgressBar – time: 1.93
GtkToggleButton – time: 3.60
GtkCheckButton – time: 2.28
GtkRadioButton – time: 5.73
GtkTextView – Add text – time: 18.81
GtkEntry – time: 1.07
GtkComboBox – time: 18.61
GtkComboBoxEntry – time: 10.98
GtkSpinButton – time: 2.81
GtkProgressBar – time: 1.51
GtkToggleButton – time: 4.31
GtkCheckButton – time: 2.60
GtkRadioButton – time: 7.42
GtkTextView – Add text – time: 12.48

 

The results are really interesting!

On the Openmoko GTA02 (Freerunner) GTK on DirectFB seems to be almost twice as fast as GTK on top of Xorg!

Even though the Hardware of the Ben NanoNote is quite limited compared to the GTA02, the benchmark looks quite promising and GTK2-applications seem to be – unline I expected – really usable on that kind of limited hardware.

What’s really confusing to me: running gtkperf on top of the accelerated Xorg-glamo driver for the glamo graphics chip is slower than using the not accelerated Xorg-fbdev driver. However this myth should not be part of this article; I’ll get in touch with Lars – the author of Xorg-glamo – regarding this issue.

UPDATE: Lars told me this is related to the glamo-overhead. Data transferred to the framebuffer via fbdev only consists of pure pixmap-data. Data transferred via the glamo-driver consists of data AND special glamo-related commands (telling the chip what to accelerate) which results in more data to be transferred. Normally this shouldn’t cause such a discrepancy, however the glamo memory-onnection is a bottleneck and only capable of tansferring around 4 MB / second which slows down unacceleraed content. The glamo chip provides the interface for the SD-card, so the whole bus is shared by graphics- and SD-carc-traffic. That’s the reason why e.g. playing videos (unaccelerated) stored on SD-card is that damn slow!

Further tests, benchmarks, evaluation coming soon…

Versions:

gtkperf: 0.40 (with patch: http://nanl.de/files/patches/gtkperf/gtkperf-adjust-layout.patch)
DirectFB: 1.4
GTK+: 2.17.0
cairo: 1.8.6
pango:1.26.0
freetype: 2.3.9
glib: 2.22.2
atk: 1.22.0
pixman: 0.14.0
Xorg X11 server: X11R7.4-1.5.1
xorg-driver-glamo: b45d78c927715b8814404fc2a34ae0aa1d003c29

Comments

23 Responses to “GTK2 running on top of DirectFB on OpenWrt!”

  1. rakshat on October 18th, 2009 7:09 am

    This should mean that Ben should also be able to use QT on DirectFB in an usable manner?

    Rakshat

  2. admin on October 18th, 2009 12:29 pm

    I’ve totally no idea about how QT works.
    It may also perform much better without having an Xserver running, but it may also work somehow different – not having such a performance discrepancy between running it on Xorg or DirectFB.

    Conclusion: I don’t think this tests result in: Every toolkit is twice as fast running on top of DirectFB than running on top of Xorg.

    But hey, give it a try :)

  3. zyth on October 19th, 2009 12:31 pm

    > GTK+: 2.17.0

    why dont u try 2.18.3 [Stable] release?

  4. admin on October 19th, 2009 2:37 pm

    Because 2.18.3 was released after I wrote and published this article :)

  5. zyth on October 19th, 2009 5:56 pm

    =) no problema you can use it “Further tests, benchmarks, evaluation coming soon…” thanx for very interesting blog..!

  6. batman52 on November 3rd, 2009 8:41 pm

    Hi,
    about the nanonote version: is it compiled with a regular glibc toolchain, or an uclibc one?

    I have tried compile gtk over directfb using the dingux kernel (see http://www.dingux.com) on a device that uses a similar SoC, but I finally gave up when i discovered that glib2 cannot be compiled against a uclibc toolchain because of the lack of internationalization support.

  7. admin on November 3rd, 2009 8:50 pm

    Hey,

    everything’s linked against the uclibc.
    Regarding the glib2 you may want to take a look at the configure-options / patches we use: https://dev.openwrt.org/browser/packages/libs/glib2

  8. batman52 on November 3rd, 2009 9:05 pm

    Wow! I’ll give it a try then! Many thanks!

  9. admin on November 3rd, 2009 9:09 pm

    Glad it may help – you’re welcome :)

  10. Alexia on November 15th, 2009 7:26 pm

    gtk 2.18.3 has the same problems with directfb as the rest up from 2.17

  11. admin on November 18th, 2009 12:39 pm

    Yep, it’s a pity :/

  12. vimrc on November 22nd, 2009 9:06 pm

    Hi,

    I tried to make it work in the Dingux, currently I have compiled all the necessary libraries successfully. However, I met a problem when execute the gtkref, it’s caused by the directFB:

    (*) DirectFB/Core: Single Application Core. (2009-11-22 12:13)
    (!) DirectFB/core/system: No system found!
    (#) DirectFBError [gdk_display_open: DirectFBCreate]: No (suitable) implementation found!

    I wrote a simple directfbrc with system and device defined and put it into the HOME but with no luck. Could you please tell me how to handle this directFB? Thanks a lot!

  13. admin on November 23rd, 2009 8:30 am

    To be honest I just “used” it – no config-file, not special configuration at all.

    AFAIK DirectFB should just open the /dev/fb0 framebuffer device and – if the framebuffer-driver is initialised and working properly – DirectFB is copying pixmaps into a special piece of memory (the fb-driver is telling) where the display controller is fetching and displaying the data in a specified interval.

    No special configuration besides a properly working framebuffer driver – sorry.

  14. vimrc on November 23rd, 2009 11:35 am

    Thanks for your information. I found an temporary solution. Batman52 and me made gtkref work in Dingux successfully yesterday. :) I am trying to handle the fonts problem..

    http://boards.dingoonity.org/dingux-development/compiling-gtk2-over-directfb-(wip)/msg4830/#msg4830

  15. admin on November 23rd, 2009 11:46 am

    Cool – why btw are you using these really olddated versions provided by ingenic?

  16. admin on November 23rd, 2009 12:07 pm

    Regarding the font problem you have: Either there are fonts missing (fontconfig is handling or them) or you don’t have a fontcache, which can be created with fc-cache.

  17. vimrc on November 23rd, 2009 12:49 pm

    Yes, i will try to fix the font. I think it’s caused by font missing. Actually most of what i am using are recent and from Openwrt except Pango and GTK+. Anyway I will upgrade Pango and GTK+ version as soon as possible. (:

  18. batman52 on November 28th, 2009 11:18 am

    Hi mirco!
    I’m getting some troubles in compiling both fontconfig and glib (the same versions as you used). did you encountered some problems in doing this?

  19. GTK2 on the NanoNote « sharism.cc on February 17th, 2010 2:50 am
  20. mobi phil on March 13th, 2010 1:58 pm

    If one would write a directfb driver (using accelerated drawing primitives), then both gtk on directfb and qt would benefit from it. I will post soon on http://mobiphil.com my experiments.

  21. Tim on March 24th, 2010 1:30 pm

    Hello!

    > gtk 2.18.3 has the same problems with directfb as the rest up from 2.17

    Are those problems critical? I mean, what GTK version is better to use now?

    (I tried to use 2.18.9 on ARM and got stuck with demo app crash, I don’t know whether it’s due to my mistakes or inner GTK issues).

  22. Vasily Khoruzhick on April 9th, 2010 3:33 pm

    > Are those problems critical? I mean, what GTK version is better to use now?

    Yes, problems are critical – DirectFB backend is heavily broken after client-side-windows merge, and it seems no one works on fix – DirectFB backend has no maintainer :(

    Last release that works is 2.16.6

  23. Cynthia on May 20th, 2011 1:24 am

    any new updates on this? what’s the latest version that works? we did left with 2.16.6.

Leave a Reply