Hi again, > libs. I am unsure of what you are trying to prove here, other than the > 100% cpu usage. I prove here that the argument "gtk is collapsing events to consume less cpu" is not valid for this case. > Qt *does* have the same problems generally (stuttering, redraws). Well not that much on my machine, maybe this varies. At least trolltech is working on performance (QT4 was mainly a performance/footprint release) instead of ignoring it. (KDE devs said to expect about 30% better gui performance jsut by switching to QT4). If you report a performance problem in qt's lists you find at least an angineer talking to you - and adressing it if its really a problem. The same way does SUN with java - I know I've filed about 30 bugs (not performance related) which got accapted. > 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. Well if it does it in software it is: * slow anyway * cpu hogging * need to copy system-ram to vram which is basically ... well god damn slow. > 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. Well XGL just uses the "underlaying" X-Server for input and mode-setting and stuff like that. So if we're talking about even delevery than yes there is overhead. For drawing theres none (except you use indirect GLX in the host-x-server). > 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). Yes but AIXGL does not use OpenGL for rendering, just for composition. Furthermore NVIDIA does not support the tuxture_to_pixmap extension (or how that stuff is called) till now. > 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. First of all its the same when moving on top of OpenGL. OpenGL drivers are far from beeing perfect and because openGL is a much more complex topic than XRender its a lot more work to get opengl drivers up and running that host X11 instead of just plain old exa drivers. I saw the proof when Sun implemented Java2d on topi of opengl - crashes, rendering artifacts and so on - they filed tons of driver bug-reports to both ATI and NVidia. Furthermore this does nothing more than hiding existing problems. As long as I move windows arround everything is fine, but as soon as I resize it or force repaint/relayouting it will be as slow as ever, maybe even slower because of the additional overhead. > that this point has caused you to understand GdkWindows and double- > buffering incorrectly. Well not all widget are GdkWindows as you noticed correctly - but from the X point of view double buffering happens at window-level. Otherwise you should say "top-window level". Furthermore the many-window model GTK uses is really inefficient for Composition - since each window's content needs to be stored inside of pixmaps. Even a single maximized GFTP window contains 15mb of pixmap data if you enable composition. You end up with having hundreds of small to medium-sized pixmap for composition - where most of them is hidden anyway by other subwindows. > 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). Wrong there was a discussion on xorg started by me where Xorg developers explaind very well why Composite is not suited for double buffering. > 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. Yes but then those are slow and need tuning. I don't see how synchronization could help here (btw as I say at least 5% are spent only in hashtable lookups!), synchronization would eliminate the flicker and half-moved windows when dragging windows really fast - but synchronization will not speed it up. > discussion about this. The last exchange you had with the list left > many people feeling frustrated. Well the last exchange I had with this list were questions about GDK/Gtk's internal stuff since I set down and did some tweaking - and got 35% more performance on my nvidia board. As soon as it started to be medium-level questions nobody answered, this leads me to the conclusion that either nobody cares about how GTK could be made faster (even if theres someone working on it) or nobody really has any clue what the hell is going on inside of GTK - at least thats how the source looks. lg Clemens _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
