RE: GTK+ 2 speed

[Michael Torrie <torriem chem byu edu>]

On Sun, 2005-07-31 at 21:54 +0100, Robert Thorpe wrote:
> It doesn't do an awful lot.  If you drag a window by the bar at its top
> across the screen then it doesn't ask the app to redraw it.  If you
> resize the edge of a window, or in any way write over what's on it, then
> by default the app redraws it.

Yes but in X11, after a console switch, the contents of the video memory
are completely erased, since text consoles share the same video memory
as the framebuffer, thus displaying all the windows again does force a
redraw (really an expose event) on all the visible windows.  And
dragging a window in Linux is fast as you have said, but all the expose
events sent to the underlying windows makes for some definite
sluggishness on the part of the other apps.

> 
> > If you use X with a composition manager (xcompmgr -a) it 
> > shows equal moving performance to windows.
> 
> I'll have to try that.  I assume this is something like using "startx
> +bs -wm"

No.  Since composite and other similar extensions are still
experimental, for now you have to tweak your xorg.conf file slightly and
then run a composition manager, such as xcompmgr.  This is similar to
how X11 requires a separate window manager.  You'll have to read up on
freedesktop.org about how to turn all these extensions on.  In the near
future, it is anticipated that desktop environments will integrate this
stuff and make it very easy.

> 
> > However there ARE X-Toolkits which handle redraws much 
> > better/faster than GTK on X, so X is no excuse for GTKs 
> > slowness, especially if you keep in mind that font-operations 
> > on client-side fonts are almost free and the 
> > primitive-rendering throughput of X is quite good.
> 
> I can certainly see the reasons for some of the slownesses (and the one
> I blamed GTK for above wasn't it's fault), but not all of them.

Part of the problem concerning redraws is the lack of synchronization
between the X11 server and the client (the GTK drawing code).  For
example, this makes resizing apps very painful, as the redraws stutter
and lag behind the dragging.  Newer extensions will allow better
synchronization to allow very smooth opaque resizes of windows, as
Windows users are used to (Windows and Mac have synchronized this
operation for quite a long time).  

Yes, as has been mentioned, font handling in GTK is slower than the core
X fonts stuff.  But I don't see how that is ever going to get a lot
faster, due to the complex nature of the things that Pango does.  Pango
currently does more with fonts and font layout than Windows XP does.
Longhorn is moving to the new Avalon GUI system and will also have a
pango-like typography system (they tell me).  We'll have to see just how
fast that works out.  Longhorn's compositing rendering subsystem
(similar to composite manager on linux) should make the perceived speed
be quite fast, though.

Profiling your app will definitely tell you where things are slow,
though. 

Michael
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
-- 
Michael Torrie <torriem chem byu edu>