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:
- Openmoko Freerunner with DirectFB
- Openmoko Freerunner with Xorg and glamo driver
- Openmoko Freerunner with Xorg and fbdev driver
- qi-hardware Ben NanoNote with DirectFB
- 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
23 replies on “GTK2 running on top of DirectFB on OpenWrt!”
This should mean that Ben should also be able to use QT on DirectFB in an usable manner?
Rakshat
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 π
> GTK+: 2.17.0
why dont u try 2.18.3 [Stable] release?
Because 2.18.3 was released after I wrote and published this article π
=) no problema you can use it “Further tests, benchmarks, evaluation coming soon⦔ thanx for very interesting blog..!
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.
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
Wow! I’ll give it a try then! Many thanks!
Glad it may help – you’re welcome π
gtk 2.18.3 has the same problems with directfb as the rest up from 2.17
Yep, it’s a pity :/
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!
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.
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
Cool – why btw are you using these really olddated versions provided by ingenic?
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.
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. (:
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?
[…] http://nanl.de/blog/2009/10/gtk2-running-on-top-of-directfb-on-openwrt/ back to ζ¬ NanoNote […]
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.
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).
> 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
any new updates on this? what’s the latest version that works? we did left with 2.16.6.