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

[Michael L Torrie <torriem chem byu edu>]

On Fri, 2006-08-11 at 17:28 +0200, Clemens Eisserer wrote:
> Hi again,
> 
> > then you'll see the repaint which may or may not be as fast as you think
> > it should be.
> And how can you explain the 100% CPU useage? If it would be idle or
> supress redraws it would not need that many cycles.

you are talking about Windows here?  Or Linux?  If it is Windows, well
all bets are off.  GTK is an X11 toolkit ported to a win32 drawing
layer.  It is not going to be ideal on Windows.  I move my windows on
linux and don't wee 100% cpu, except in frequent, occasional (and
expected) spikes.

> 
> > frame rate, everything does get smoother.  The biggest win here is
> > resizing a window.  With the proposed X11 synchronization extension
> > stuff (as I understand it), GTK app resizes will be silky smooth (well
> > at a frame-rate your computer can handle CPU-wise).
> A simple example - placing two tables with some data (maybe 10 text
> clumns) in a PannedWindow maximize the window to 1600x1200 and move
> the gripper. CPU goes up to 100% while animation is slow.
> This has nothing to do with event processing - at least 10% of total
> CPU time is spent in glibs data structures. This is on a 2.6ghz
> pentium 4 Northwood - so I don't talk about pentium1 or 486.

Just because 10% of the cpu time is spent in the glibs "data structures"
in no way means that it isn't event processing that is taking the time.
Event processing (reacting to the events) is handled in the GDK and GTK
libs.  I am unsure of what you are trying to prove here, other than the
100% cpu usage.

> 
> > X11 that will allow Gtk (and Qt and any other widget set) to be able to
> > resize fluidly."
> Well I don't have any problems with QT, Fox-Toolkit or Fltk.
> And I would call QT even more feature-rich and fatter - but it does
> not suffer from those performance problems.

Qt *does* have the same problems generally (stuttering, redraws).

> 
> > No you are incorrect.  OpenGL is not only fast at 3d but also 2d.
> > However this is beside the point.
> OpenGL is fast if you do special stuff thats not possible through X11
> (where you would e.g. need software fallbacks) but most guys draw
> lines and fill rects and this is where OpenGL really sucks - just
> because its much more complex and has a deeper ... I would call it ..
> well ... driver pipeline.
> Thats also why NVIDIA developers said that they would support a major
> transition to XGL but they would not recommend it from the performance
> pov. and these guys should know ;-)

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.

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.  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).

> 
> > Of course.  But OpenGL makes the composite manager very fast.  In short,
> > composite is slow and CPU intensive without OpenGL.
> No - why should it be slow? I don't talk about effects, just good
> plain old composition maybe with shadows. This can be done through
> XRENDER without any CPU hit (at least on my nvidia gpu). If you don't
> use fancy effects composition can even be done using the old "core"
> instruction set, painting pixmaps is accalerated more or less
> everywhere.

Umm composite is naturally slow because each window layer has to be
mathematically combined together before displaying on the window.
OpenGL offloads this to the render hardware which does this kind of
thing at 60 frames a second.  Yes Nvidia's driver can offload composite
to the card.  But in the case of the nvidia driver, composite is very
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.  Xgl and AIXGL make
composite a stable standard. 

> 
> > In answer to your original question, GTK apps are double-buffered at the
> > widget level, not the window-contents level.
> GTK's widget are double-buffered at window-level, I would have a look
> at gdkwindow.c.

Each GTK application window consists of dozens or hundreds of gdk
windows.  In X terminology, a window is a small region that accepts
events from the X server.  Each widget that receives events like clicks
is a GdkWindow (and also an X Window).  I could be wrong, but I believe
that this point has caused you to understand GdkWindows and double-
buffering incorrectly.

Therefore, I don't believe GTK apps are double-buffered at the window-
contents level.  If they are, I believe the code would be in GtkWindow,
not GdkWindow.

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).

> 
> > I doubt you'll find anyone complaining about GTK speed.
> > It's been shown on this list and in other places to largely be a
> > perception issue.

By chopping up my comments you are taking them out of context.  I didn't
say "I doubt you'll find anyone complaining about GTK speed."  I said
that with Xgl or AIXGL, combined with the synchronization stuff, then I
doubt that you will find that.

> Well the example I gave (resizing a PannedWindow with table, tree or
> richtext widgets) will stay slow or be even slower when running on
> XGL, its not related to synchronization nore to event-buffering
> mechanismns, since CPU is working at 100%.

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.

> 
> I'll work out some benchmarks comparing GTK with QT. Both are feature
> rich and fat so they  can be compared well. I just would like to have
> results handy - I am tired of explaining again and again why I think
> GTK is slow (and why do so many others dislike it because of its weak
> performance?). I am quite sure - if I have the results my code will be
> as long analyzed to find unfair advantage sof the qt part and if there
> are none and QT is still faster .... the thread will die and nobody
> will care.

Proper benchmarks will always be useful and acceptable to the GTK
developers I think.  Then at least there will be real numbers to discuss
with you.

Likely this thread will die. It's not that no one cares; it's that,
likely due to the e-mail medium, it is difficult to have a constructive
discussion about this.  The last exchange you had with the list left
many people feeling frustrated.


> 
> lg Clemens
>