Q: Xserver / Composite behavior

[Russell Shaw]

Keith Packard wrote:
> On Sun, 2006-01-08 at 12:34 +1100, Russell Shaw wrote:
> 
>>Isn't that a bit inefficient? If you had a 1000x1000 window scrolled
>>outside the root, it'd be wasting 4MB in a useless pixmap. No wonder
>>X is so slow;)
> 
> Actually, one of the key lessons of the last ten years is that perceived
> window system performance is based almost entirely on the appearance of
> rendering artifacts on the screen. 
> 
> We learned this from Mac OS X which was initially distributed with all
> rendering entirely software based, and with which objective performance
> measurements showed to be one of the slowest drawing environments in
> existance. However, because the entire display was artifact-free, due in
> large measure to the composited window system architecture, users
> perceptions were of a high-performance and responsive system.
> 
> The perception of poor X performance can now be understood because it
> presents more artifacts than other systems; indirect window management
> provides benefits in utility at the cost of ugly reconfiguration,
> especially resize. Lack of universal double-buffering means applications
> often present intermediate window contents to the user.
> 
> Objectively, X is the fastest 2d drawing environment out there, only
> through methods like Composite which seek to reduce artifacts will we
> see perceptions about the system behaviour improve.
> 
> Yes, every window will suck way more memory; we have the benefit at
> least of allowing users to memory for a better experience; something
> lacking in OS X where compositing is required. As this amount of memory
> becomes a smaller fraction of the available space, it will begin to make
> sense for more users to spend it in this way.

As long as X always has a way such that you can create windows that don't
require an offscreen pixmap, a lot of lower end (embedded) users would be
happy.

I've found screen artifacts by some widget kits are just due to poor
widget code that do things like throwing away all sequential expose
events except for the last one (they should aggregate *all* expose
areas into one region, then draw that). They even use double buffering
unnecessarily.

Poor widget coding persists when toolkits insists on layers of useless
wrappers that get between the programmer and the interface that does all
the work (Xlib), hiding the optimizations possible in a natively client-server
windowing system.

Just because memory might cost $20/GB, doesn't make it good to write stuff
that is only responsive on 100+MHz pentiums. There's no reason why a decent
2D gui can't be blazingly fast on a 25MHz 386 with X.

Old laptops are very useful things if they can work adequately with X.