RE: Embedded Gtk+ system moving to 2.14

["Boncek, John" <jboncek hunter com>]

Thank you.  You've given us a great pointer to what might be a problem area.  We are using the PXA270 
processor and according to our kernel guy it appears we do in fact have the kernel emulation of hard floating 
point instructions turned on.  We had never looked into the different solutions for floating point in any 
great detail.

-----Original Message-----
From: John K. Luebs [mailto:jkluebs roctown com]
Sent: Monday, February 23, 2009 4:01 AM
To: Boncek, John
Cc: gtk-app-devel-list gnome org
Subject: Re: Embedded Gtk+ system moving to 2.14

John Boncek wrote:
>  Attempting to move several large (multi-hundred compile units) C++
>  application programs of an embedded ARM / Linux 2.4 system from Gtk+
>  2.2.4 to Gtk+ 2.14.  We are noting severe performance degradation
>  (2-3 times) in screen transitions and a definite overall sluggishness
>  to the systems. There are no profiling tools available on ARM / Linux
>  2.4 that we have been able to find despite a lot of online
>  investigation.
>
>  Does anyone know of particular parts of Gtk+ that have become
>  significantly slower across this rather large jump in versions?  Any
>  pointers on where to look in our systems would be appreciated.
>
>  Sincerely, John Boncek
As others have mentioned, the use of cairo is one of the major
differences between
the two versions of GTK+ you mention. cairo is quite floating point
intensive, which
could be a big problem for the ARM. Previous to use of cairo, GTK+ and
the rest of
the GUI stack was relatively free of floating point in the core drawing
paths.
Also, libpixman has improved over the years but unfortunately, unless
you are using a modern ARMv6
or greater architecture with SIMD support, the ARM specific
optimizations in pixman
are not usable.

Since you mention linux 2.4, it sounds like you are working with an
older system. Are you using software
floating point? Kernel emulation of hard floating point instructions is
very likely to give awful performance.
It is also preferable, if using gcc, to use the handwritten assembly
floating point
functions (defined in gcc/config/arm/ieee754-{d,f}.S) that are built
into libgcc rather than linking with a libfloat
library built from C code, as has been done in the past.

  -jkl