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 > _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
