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:[email protected]] 
Envoyé : 21 août 2009 10:04
À : Pier Castonguay
Cc : [email protected]
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
> [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

Reply via email to