[maemo-developers] [maemo-developers] Irrelevant comparisons (was Re: testing pango with 770)

[From: Eero Tamminen]

Hi,

On Wed, Dec 28, 2005 at 02:46:15PM +0100, Clemens Eisserer wrote:
> wow this seems to develop to a real flamewar ;)

I don't see any flames. :-)


> > I think it's useless to compare things that don't have the same
> > features.  If something doesn't have a required feature, all of
> > its apparent "speed" is useless.
> >
> > (Note: Qt >v2 is something you could feature-wise compare to
> > current Gtk, but e.g. current Qtopia is based on Qt v2.)
>
> This is the default "it has soo many features so it is slow and
> there's no way arround that" argument.

The main point is that you cannot have proper argument without
something comparable.  After those, you can measure.  Without
proper measurements all arguments are just mildly warm air.

If the "problem" doesn't concern anybody enough even to measure
how long something takes, it's hard to convince anybody that
it's a problem.  If the measurements show that something else
does the same set of features significantly faster, that's
a very good argument...


> I did not compare QTopia with GTK since those are quite different
> things, I spoke about QT-4 vs GTK2 on top of an Xserver which has not
> to do a lot with handhelds but with toolkit performance in general.
> 
> > Because of first, yes, it's faster, but it's also unusable
> > un-professional looking due to flickering drawing (check e.g.
> > how awful menus in Gnome 1.x look) and crappy looking fonts.
>
> Hmm, yep it flickers but on the other side resizing windows or
> sub-windows is incredible slow with GTK2.

I think this might be due to high amount of signaling, especially
with deep widget hierarchies.


> QT4 is quite good when it comes to dynamic layouting and includes
> almost everything (or even more) which is built into GTK2.

It could be that Qt widget hierachies are either more shallow,
signaling is faster, there happens less of it or redraws are faster.
Alternatively, it could be an issue of latency instead of speed.
Or that you're testing different things... :)

It would be nice to construct similar widget hiararchies in both
Gtk2 & Qt4 and measure their performance on resize.  Some tools
that could be used in this:
- Xephyr: do "killall -SIGUSR1 Xephyr" and it will visualize
  everything that's drawn on the screen (i.e. is there redundant
  redrawing)
  http://www.freedesktop.org/wiki/Software_2fXephyr
- Xresponse: times user response times
  http://projects.o-hand.com/xresponse/

Re-compiling Gdk with the debug option to show what expose events
it recieves might also be instructive.

Or then one could just add timestamps on the code implementing
these test programs.


> > Pango is also a known bottleneck, but without it the Gtk
> > users would be restricted mostly to the English speaking
> > minority <insert here "Hello world!" in Chinese and Indic/>.
>
> QT can do the same and is faster. I don't know why nore do I care, I
> am a java developer so these things do not really count for me - I am
> a user-only and quite bothered by slow GTK UIs.

In this case it would be good to have the same text test-cases
implemented and measured also for Qt.


	- Eero

> lg Clemens
> 
> PS: Peace