Re: Gtk on Embedded Device Query

["Saroj Kumar" <saroz kumar gmail com>]

Hi , 

Thanks for the reply.
Anyhow I have to use this system for my application. I agree that this system is having slow processor speed. But lower than this configuration, processors running on mobile devices performing well in terms of GUI. So, I thought gtk+ (gtk-directfb) will help me in this.  

Now it seems that gtk+ is not suited for embedded devices. Or is there any way to make it work fast. 

<The Main problem here is while drawing gtk widgets on screen my CPU usage goes upto 92%. Any button press in window also make CPU usage more.>

Thanks and Regards,
Saroz

On Nov 29, 2007 1:16 PM, Kalle Vahlman <kalle vahlman gmail com> wrote:

This doesn't really belong to gtk-list, so I'm leaving it out.

2007/11/29, Saroj Kumar <saroz kumar gmail com>:

>    Hi,
> >
> > I am running gtk+ application on an embedded board (PXA255 processor with
> 400MHz speed) running Linux.
> > Gtk+ is running on top of frame buffer (instead of X11).
> > Application is running very slow on the board.
> >
> > Compared to desktop Linux system its 20 times slower. (Found out by
> testing GtkPerf application)

That's not really a worthwhile test, comparing an embedded device to a
desktop machine. I think you can already guess the result without
running GtkPerf at all.

> > Is there any way to make it fast?
> > I ran gtk-demo for testing, that one also very slow.

The more interesting are the things that are not fast. Here is a list
of common reasons for (ARM) devices off the top of my head (we have
run into these a lot at work):

 * Memory performance
  * Often the memory bus of embedded devices is really not that fast
  * If you have a generic toolchain/libc, memcpy() and related
functions may be using implementations that are very slow for that
hardware
  * Makes eg. blitting images slow, as that usually reduces to memory transfers

 * CPU performance
  * Older embedded processors(/architectures) just aren't too fast.
  * Older embedded processors usually do not include any floating
point support (eg. VFP) so any floating point operations will hurt.
  * Doubly so if not running an EABI system (OABI systems have really
sucky floating point emulation scheme, EABI fixes that)

 * Graphics performance
  * Usually there is no dedicated HW for graphics operations, so it
strains the cpu with software fallbacks and the memory badwith with
more data transfer.

One big factor also is that not all code is free of doing silly things
that just are not visible on desktop-class machines. It only needs a
small repeated operation that's invisible on multigigahertz-x86 to
bring an embedded device down to its knees, should it be just the one
that happens to be extremely slow on that particular hardware.

So in short, before wondering why GTK+ is slow, make sure that your
system is fast and optimized (and then profile&optimize the slow spots
in GTK+).

--
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi