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