Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  PC X servers / backing store
Message-ID: <9103031314.AA26858@lightning.McRCIM.McGill.EDU>
Date: 3 Mar 91 13:14:50 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 55

>>> The suppliers of Grafit informed me that the X server
>>> implementation probably did not support backing store  - a
>>> requirement for their package ( or for the HP Starbase/X
>>> implementation? ).

>> Then their package is buggy.

> This is absolutely untrue.  Backing store is a feature just like
> colors, visuals, shape extensions, pex and everything else.  There is
> nothing wrong with a package requiring properly working backstore for
> that package to work.

There is nothing improper about a backing-store implementation that
doesn't always maintain a backing image.  The server is - and always
has been - permitted to stop maintaining backing-store at any time, for
any reason (such as running short of memory).  Perhaps there should
have been another value for the backing-store hint that says "I want
backing-store, and I want an error if you can't commit to it", but
there isn't.

> The graphics that are being generated maybe entirely to complex to
> redraw efficiently if an expose event occurs.

That's what I meant about "if they must have backing-store style
semantics".  Yes, there is a large class of programs for which it is
impractically expensive to regenerate the image; such programs should
maintain their own store, either in a pixmap on the server or in an
image on the client.

> Saying that the clients should do it's own backing store if the
> xserver can't do it is like saying the client should map colors to
> dither patterns if it sees a b/w color terminal,
(What, pray tell, is a "b/w color terminal"?)
> or automatically scale a drawing down if the terminal's resolution is
> not large enough to present a satisfactory

(A satisfactory *what*?)  Yes, you could look at it that way.  I prefer
to look at it more along the lines of requiring the server to maintain
backing-store is like requiring the screen to be 1152x900: it is
unreasonable.  Sure, you can write a program that works only on servers
that have 95 keys and a screen of 1120x832 pixels.  I would call such a
program buggy just as fast as I would one that demands backing-store.

> Sure these are nice things to have but sometimes the resulting
> product in such a degraded state on a X server that just does not
> have the right capabilities is just a waste of programmer effort.

Certainly.  But some things are unreasonable to demand.  I think the
demand under discussion is unreasonable.  Clients have always been
required to handle Expose events; why should this change now?

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu