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

["Clemens Eisserer" <linuxhippy gmail com>]

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.

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

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

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

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

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

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

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.

lg Clemens