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