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 <[EMAIL PROTECTED]> wrote: > This doesn't really belong to gtk-list, so I'm leaving it out. > > 2007/11/29, Saroj Kumar <[EMAIL PROTECTED]>: > > 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, [EMAIL PROTECTED] > Powered by http://movial.fi > Interesting stuff at http://syslog.movial.fi >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
