Hi Pier,
thanks for sharing the progress, interesting read.
Some small comments:
I am assuming you are the latest version of gtk+, since there have been
issues reported with updating/show on older versions.
Strange that pango would have such an influence; I assume you mean pango
through cairo, since pango does not rely directly on dfb. Would be
curious where the performance is lost, if that would be easy to find out.
Pier Castonguay wrote:
Hi Niels,
Thx for the answer, even if late.
You are right, my device don't use any hardware gfx acceleration.
About my TSLIB problem, it was because I had PS/2 inputs configured too and
it was giving two different inputs at once at every click.
I've made a long way since then. Managed to use crosstool-ng to create a fpu
patched, up-to-date gcc/glibc crosscompiler, using the EABI interface. This
gives a massive speed boost. I then compiled over 20 libs with it, creating
a basic rootfs. Then compiled DFB, with cairo and gtk+ using it's backend.
It's faster, but because of EABI, not directfb.
I'm now trying (with difficulties, their script seems bugged) to
cross-compile Xorg instead of DFB for many reasons:
-GTK+ refreshing handle differently. On call .show() DFB show to window
(with old content), then repaint. With X it repaint, then show. Some things
simply never repaint with DFB.
-TSLIB sometime don't send the button_release event.
-Most importantly, pango with DFB is a MASSIVE bottleneck. Refreshing a
single label (a clock) every second with Xorg-OABI takes 10% cpu, with
DFB-EABI it takes 50%!.
More info about my findings are there:
http://tech.groups.yahoo.com/group/ts-7000/message/15711
-Pier Castonguay
-----Message d'origine-----
De : Niels Roest [mailto:ni...@directfb.org]
Envoyé : 21 août 2009 10:04
À : Pier Castonguay
Cc : directfb-users@directfb.org
Objet : Re: [directfb-users] GTK-Direct FB not much faster than GTK-Xorg
Hi Pier.
late answer but maybe still interesting.
DirectFB has two main reasons for giving a speed boost:
- simpler architecture - this is more or less swallowed by the other
packages build on top
- hardware acceleration - this is probably your problem - you need a
graphics driver for your TS, which I am guessing you don't.
Fusion is not your problem, this line:
(*) DirectFB/Core: Single Application Core. (2009-06-23 13:00)
states that it is running in "single" mode (instead of "multi") so
without fusion interfering.
I cannot comment on the touch screen, don't know where the location
problem is coming from.
You might wanna configure directfb with "--enable-debug" and use a
directfbrc with "debug=Core/Input/Evt" or "debug=Core/Input" for more
debug messages about event handling.
Greets
Niels
Pier Castonguay wrote:
Hello all.
After a while, I finally managed to port my GTK+ application to use
DirectFB instead of Xorg. Unfortunately, it did not give the speed
boost I was expecting.
My device is a TS-TPC-7390 running a Cirrus EP9302 processor (ARM920T)
so the architecture is armv4tl. Here is what I did, and fortunately
someone can point me to something I did wrong/forgot.
I have Debian-etch from TS website, and found out most libs were too
old to enable DirectFB support in GTk+, so I started rebuilding them
all from source. I realized afterward that I should have simply
upgraded my distribution, but anyway. Here a list of what I recompiled
(versions which are a few years more recent than what I had):
autoconf / automake / libtool / gettext / glib / glibmm / atk / cairo
/ cairomm / fontconfig / freetype / gtk+ / gtkmm / jasper / libglade /
libglademm / pango / pangomm / pixman / tiff / tslib
So as you can see, this is quite a bunch. I first compiled them with
“-g” flag, and afterward used “strip –strip-unneeded” to remove debug
information, which got a small speed gain, but not that much.
I didn’t have to specify any special settings to DirectFB, seems like
it detected my framebuffer with no problems. Application ran with no
problems, simply some minor gfx glitch (not big problem). I also have
some warning messages. Here is the DFB log when starting the application:
~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.3.1 |~~~~~~~~~~~~~~~~~~~~~~~~~~
(c) 2001-2008 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
----------------------------------------------------------------
(*) DirectFB/Core: Single Application Core. (2009-06-23 13:00)
(*) Direct/Memcpy: Using armasm_memcpy()
(*) Direct/Thread: Started 'VT Switcher' (1463) [CRITICAL OTHER/OTHER
0/0] <2093056>...
(*) Direct/Thread: Started 'tslib Input' (1464) [INPUT OTHER/OTHER
0/0] <2093056>...
(*) DirectFB/Input: tslib touchscreen 0 0.1 (tslib)
(*) Direct/Thread: Started 'PS/2 Input' (1465) [INPUT OTHER/OTHER 0/0]
<2093056>...
(*) DirectFB/Input: IMPS/2 Mouse 1.0 (directfb.org)
(*) Direct/Thread: Started 'Linux Input' (1466) [INPUT OTHER/OTHER
0/0] <2093056>...
(*) DirectFB/Input: CHICONY USB Keyboard 0.1 (directfb.org)
(*) Direct/Thread: Started 'Keyboard Input' (1467) [INPUT OTHER/OTHER
0/0] <2093056>...
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
(*) DirectFB/Graphics: Generic Software Rasterizer 0.6 (directfb.org)
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
(*) FBDev/Mode: Setting 800x480 RGB16
(*) FBDev/Mode: Switched to 800x480 (virtual 800x480) at 16 bit
(RGB16), pitch 1600
(*) FBDev/Surface: Allocated 800x480 16 bit RGB16 buffer (index 0) at
offset 0 and pitch 1600.
(tmg-arm:1434): Gdk-CRITICAL **: gdk_drawable_set_colormap: assertion
`cmap == NULL || gdk_drawable_get_depth (drawable) ==
cmap->visual->depth' failed
(*) Direct/Thread: Started 'EventBufferFeed' (1468) [MESSAGING
OTHER/OTHER 0/0] <2093056>...
(tmg-arm:1434): Gdk-DirectFB-WARNING **: gdk_window_set_keep_above()
not implemented.
(tmg-arm:1434): Gdk-DirectFB-WARNING **: gdk_window_set_keep_below()
not implemented.
Also, when I kill the application:
(!!!) *** WARNING [still objects in 'Window Pool'] *** [object.c:241
in fusion_object_pool_destroy()]
(!) [ 1434: 0.073] --> Caught signal 2 (sent by the kernel) <--
(!!!) *** WARNING [still objects in 'Layer Region Pool'] ***
[object.c:241 in fusion_object_pool_destroy()]
(!!!) *** WARNING [still objects in 'Layer Context Pool'] ***
[object.c:241 in fusion_object_pool_destroy()]
(!!!) *** WARNING [still objects in 'Surface Pool'] *** [object.c:241
in fusion_object_pool_destroy()]
I don’t think it’s anything problematic.
Since my application is alone, could I bypass Fusion? Would it improve
performances? Any other things I should look for performance?
Another big problem is the input of the touchscreen. When I was using
directly the kernel module and Xorg, it was behaving a lot better than
it is now using TSLIB. I have calibrated it with ts_calibrate, set up
the ts.conf file and the env variables, and dfb use it. When I press,
the cursor is set about 200 pixels from where I clicked, and then
moves very quickly to the correct position. Holding the cursor and it
eventually get to the correct place, but quickly clicking don’t. Also,
some clicks don’t get handled, and most importantly, it sometimes
randomly click to places far away from where I pressed (the
~200pixels). Judging from my start log above, it loads the PS/2 mouse
(don’t have any) and it loads the keyboard twice. Could they interfere
with the touch screen input?
Anything else I should know??
Thx for any help.
-Pier Castonguay
------------------------------------------------------------------------
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
