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
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
