Re: Snappy GUI response

On Fri, Jul 04, 2003 at 11:05:04AM -0700, Mark Vojkovich wrote: 
>    I advocate backing pixmaps for as many windows as it 
> makes sense, and no expose events on them.  Not only is this
> extremely fast even if server is rendering in software, but
> it looks great (you don't see redrawing).  That is, save all
> your expensive rendering, don't keep redrawing it.  Put it in
> a pixmap and set it as the window background.  There's also
> a good change this pixmap will end up in video ram rather than 
> system ram.

As I understand it this is pretty much what OS X does - it just keeps
around the contents of every window. You have to do this anyway to
implement alpha-blended windows, from what people have said.

It might be possible to more or less implement this in toolkits (the
"keep pixmap for all windows" thing, not the alpha thing).  It could
also be done in the server presumably.
 
>    The window manager is an app.  The modern window manager's
> performance sucks as bad as the rest of the apps.  I looked at RH 8
> or 9 (don't remember which) and the root window was obviously being
> painted via expose events rather than letting the server handle
> it automatically.  It looked really bad and contributed alot to
> the sensation of watching things repaint.

The desktop background isn't handled by the window manager anymore,
it's nautilus in GNOME and a dedicated app called kdesktop in
KDE. These apps are putting a large window over the top of the root
window containing the desktop icons.

Nautilus in Red Hat 7.3 was fixed to set background instead of
handling exposes here, it regressed in 8 for obscure reasons (the
original set background fix was a complicated hack that punched
through the abstraction layers of the library stack and ended up
breaking).  It is fixed in latest GNOME and probably in RHL9 though,
for the areas of the background that don't contain icons. (i.e. it
sets the X window background to your background image or solid color,
but the X window background doesn't include the icons and exposes are
handled for those.)
 
>    Maybe whatever the apps are doing are thwarting toolkit optimization
> and it's not the toolkit's fault, but whoever is doing it, it's why 
> everything looks so slow.

The cause and the fix vary widely by specific context and specific
application... a global solution in the server or toolkits is very
attractive for that reason.

Havoc