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 09:57 +0200, Clemens Eisserer wrote:
> Hi again,
> 
> Well there has been a lot of discussion about GTKs performance, wether
> its fast or not.
> I just found that moving a window on top of a GTK window on Windows I
> get 100% CPU on a XP2200+/WindowsXP and visible repaint lags - be that
> slow or fast ... I don't want to comment.

GTK performance on Windows is a red herring, really.  And from what I
can see, probably because of the way windows events work, GTK apps will
freeze all their windows while moving the window, so you won't see lags
in the repaint; you'll just see nothing until the window is moved and
then you'll see the repaint which may or may not be as fast as you think
it should be.  Under Xgl, and any of the new opengl backends, you should
find almost no cpu use when dragging the window.

> Tearing is caused by the fact that applications don't paint themself
> fast enough, not because drawing is not synchronized. Draw a window on
> top of a maximized xcalc and you won't see any tearing.

You are wrong. The visible application redraw, either during expose or
configure events, is very much a synchronization issue.  Sure redrawing
at light speed would eliminate the symptom, but it wouldn't address the
problem (and it would be very inefficient anyway).

Sure Xcalc redraws itself fast enough so as not to have visible
redrawing because the ops are very simple.  However, most of the time on
my fast nvidia graphics card and machine I can't see GTK apps redraw
either.  GTK is orders of magnitude more complicated and intensive that
the Xaw widgets.  GTK widgets are all dynamically sized on the fly.
That is one reason why GTK may be slower to redraw than Xaw.  But Xaw is
not very useful and you wouldn't want to make a full app out of it.

Back to synchronization.  The problem is that as you rapidly move one
window past another, or resize a window, the events queue up and ask the
app to redraw.  However the redraw app will likely have to happen all
over again before redraw is finished. So GTK queues up the events,
halting the redraw momentarily.  The upshot of this is that you save a
lot of CPU and in the end redraw faster (cause you're only doing it 5
times instead of 1000), but there is visible stutter.  If the redraw
events and the movement of the windows are synchronized according to a
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).  

Here is a quote from an unknown source that explains it better: "Because
X11 is asynchronous, as the window resizes, configure and expose events
are sent to the GTK widgets to get them to redraw. Because of this
asynchronous nature, until recently there was no good way to synchronize
the redrawing to the actual expanding of the window, as OS X and Windows
do. This is changing and a synchronization mechanism is being built into
X11 that will allow Gtk (and Qt and any other widget set) to be able to
resize fluidly."

> This is basically wrong. Drawing primitives through OpenGL is very
> likely to be a lot slower than through accalerated X11 drivers, I
> would give x11perf a try on XGL.
> I would not consider drawing to be the largest problem anymore,
> espacially when it comes down to GTK+ performance problems. Readbacks
> and

No you are incorrect.  OpenGL is not only fast at 3d but also 2d.
However this is beside the point.  Xgl uses OpenGL to display window
contents as textures. Thus GTK apps render as normal (or with Cairo) to
a texture in memory (just like they did before), but this texture is
rendered to the screen, with special effects like shadows and
transparency at 30-60 frames per second.  Cairo is also moving to render
paths directly in OpenGL, which should speed up all advanced Cairo
operations.

> Well thats not OpenGL related and is basically what a Composition manager does.
> However toolkits should be fast enough also without composition, and a
> lot toolkits prove that it is no problem for them (Fox-toolkit, fltk,
> qt, win32, ....).

Of course.  But openGL makes the composite manager very fast.  In short,
composite is slow and CPU intensive without OpenGL.  This allows windows
to move without any redraw at all, very quickly, and with transparency,
3-d effects, full Xvideo support/emulation, etc.  Interestingly enough,
I tried out composite years ago back on a Vesa-only X server (some
experimental server from freedesktop.org) and even though we *know* that
Vesa is slower in every way, composite made it feel faster.  It wasn't
really, but it seemed that way.  With OpenGL it can seem faster and
actually be faster too (or at least as fast as it always was).

In answer to your original question, GTK apps are double-buffered at the
widget level, not the window-contents level.  Xgl and AIXGL (composite
generally) make all apps "double-buffered" at the window level,
eliminating expose redraws entirely, speeding up every window operation
except resize, which still depends on the speed at which the widgets can
dynamically resize.  

Once Xgl and AIXGL become widespread, and the synchronization mechanism
is released, 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.

Now, GTK2 is slower than GTK1.  It's also more complicated.  It won't
work as well on a 486 or a pentium 1.  If you want to target an older,
slower platform, or an embedded device, and you think GTK2 is too slow,
either real or perceived, then yes, move to another toolkit that's
lighter.  GTK is advancing far beyond FLTK or many of the other light
toolkits.  It does more than just GUI stuff.

Michael


> 
> lg Clemens
>