On Sun, 2005-07-31 at 21:54 +0100, Robert Thorpe wrote: > It doesn't do an awful lot. If you drag a window by the bar at its top > across the screen then it doesn't ask the app to redraw it. If you > resize the edge of a window, or in any way write over what's on it, then > by default the app redraws it. Yes but in X11, after a console switch, the contents of the video memory are completely erased, since text consoles share the same video memory as the framebuffer, thus displaying all the windows again does force a redraw (really an expose event) on all the visible windows. And dragging a window in Linux is fast as you have said, but all the expose events sent to the underlying windows makes for some definite sluggishness on the part of the other apps. > > > If you use X with a composition manager (xcompmgr -a) it > > shows equal moving performance to windows. > > I'll have to try that. I assume this is something like using "startx > +bs -wm" No. Since composite and other similar extensions are still experimental, for now you have to tweak your xorg.conf file slightly and then run a composition manager, such as xcompmgr. This is similar to how X11 requires a separate window manager. You'll have to read up on freedesktop.org about how to turn all these extensions on. In the near future, it is anticipated that desktop environments will integrate this stuff and make it very easy. > > > However there ARE X-Toolkits which handle redraws much > > better/faster than GTK on X, so X is no excuse for GTKs > > slowness, especially if you keep in mind that font-operations > > on client-side fonts are almost free and the > > primitive-rendering throughput of X is quite good. > > I can certainly see the reasons for some of the slownesses (and the one > I blamed GTK for above wasn't it's fault), but not all of them. Part of the problem concerning redraws is the lack of synchronization between the X11 server and the client (the GTK drawing code). For example, this makes resizing apps very painful, as the redraws stutter and lag behind the dragging. Newer extensions will allow better synchronization to allow very smooth opaque resizes of windows, as Windows users are used to (Windows and Mac have synchronized this operation for quite a long time). Yes, as has been mentioned, font handling in GTK is slower than the core X fonts stuff. But I don't see how that is ever going to get a lot faster, due to the complex nature of the things that Pango does. Pango currently does more with fonts and font layout than Windows XP does. Longhorn is moving to the new Avalon GUI system and will also have a pango-like typography system (they tell me). We'll have to see just how fast that works out. Longhorn's compositing rendering subsystem (similar to composite manager on linux) should make the perceived speed be quite fast, though. Profiling your app will definitely tell you where things are slow, though. Michael > _______________________________________________ > > gtk-list@xxxxxxxxx > http://mail.gnome.org/mailman/listinfo/gtk-list -- Michael Torrie <torriem@xxxxxxxxxxxx> _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
