Re: GTK is double buffered by default ? on GNU/Linux and MS Windows ?

["Clemens Eisserer" <linuxhippy gmail com>]

Hi again,

> libs.  I am unsure of what you are trying to prove here, other than the
> 100% cpu usage.
I prove here that the argument "gtk is collapsing events to consume
less cpu" is not valid for this case.

> Qt *does* have the same problems generally (stuttering, redraws).
Well not that much on my machine, maybe this varies. At least
trolltech is working on performance (QT4 was mainly a
performance/footprint release) instead of ignoring it.
(KDE devs said to expect about 30% better gui performance jsut by
switching to QT4).
If you report a performance problem in qt's lists you find at least an
angineer talking to you - and adressing it if its really a problem.
The same way does SUN with java - I know I've filed about 30 bugs (not
performance related) which got accapted.

> You're missing the point.  Xgl currently doesn't use OpenGL for
> rectangles and lines.  It uses OpenGL to rapidly render textures.  So
> there's no speed penalty at all.
Well if it does it in software it is:
* slow anyway
* cpu hogging
* need to copy system-ram to vram which is basically ... well god damn slow.

> And frankly the NVidia comments are bogus, or at least misunderstood by
> you.  Xgl is an X server that runs on top of X11, so there's overhead
> there.
Well XGL just uses the "underlaying" X-Server for input and
mode-setting and stuff like that. So if we're talking about even
delevery than yes there is overhead. For drawing theres none (except
you use indirect GLX in the host-x-server).

> NVidia *is* supporting the method used by AIXGL, which *is*
> fast.  These technologies *will* make everything including Qt, Gtk, FLTK
> feel faster (except in your divider drag example).
Yes but AIXGL does not use OpenGL for rendering, just for composition.
Furthermore NVIDIA does not support the tuxture_to_pixmap extension
(or how that stuff is called) till now.

> buggy and it is recommended you disable it.  BUT, as you know perfectly
> well, with composite turned on, moving one GTK window across another
> feels fast and smooth with no tearing or stuttering.
First of all its the same when moving on top of OpenGL. OpenGL drivers
are far from beeing perfect and because openGL is a much more complex
topic than XRender its a lot more work to get opengl drivers up and
running that host X11 instead of just plain old exa drivers.
I saw the proof when Sun implemented Java2d on topi of opengl -
crashes, rendering artifacts and so on - they filed tons of driver
bug-reports to both ATI and NVidia.

Furthermore this does nothing more than hiding existing problems. As
long as I move windows arround everything is fine, but as soon as I
resize it or force repaint/relayouting it will be as slow as ever,
maybe even slower because of the additional overhead.

> that this point has caused you to understand GdkWindows and double-
> buffering incorrectly.
Well not all widget are GdkWindows as you noticed correctly - but from
the X point of view double buffering happens at window-level.
Otherwise you should say "top-window level".
Furthermore the many-window model GTK uses is really inefficient for
Composition - since each window's content needs to be stored inside of
pixmaps. Even a single maximized GFTP window contains 15mb of pixmap
data if you enable composition.
You end up with having hundreds of small to medium-sized pixmap for
composition - where most of them is hidden anyway by other subwindows.


> Besides that, it's really not GTK's place to double-buffer the entire
> application window.  That's the responsibility of the X server (and
> composite does do this).
Wrong there was a discussion on xorg started by me where Xorg
developers explaind very well why Composite is not suited for  double
buffering.


> All resizing problems can be helped by synchronization.  In situation it
> is probably the complicated calculations being run to dynamically resize
> the widgets that is taking 100% of the cpu.  However I don't know.
Yes but then those are slow and need tuning. I don't see how
synchronization could help here (btw as I say at least 5% are spent
only in hashtable lookups!), synchronization would eliminate the
flicker and half-moved windows when dragging windows really fast - but
synchronization will not speed it up.

> discussion about this.  The last exchange you had with the list left
> many people feeling frustrated.
Well the last exchange I had with this list were questions about
GDK/Gtk's internal stuff since I set down and did some tweaking - and
got 35% more performance on my nvidia board.
As soon as it started to be medium-level questions nobody answered,
this leads me to the conclusion that either nobody cares about how GTK
could be made faster (even if theres someone working on it) or nobody
really has any clue what the hell is going on inside of GTK - at least
thats how the source looks.

lg Clemens