Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: dshr@eng.sun.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: backing store
Message-ID: <9103041642.AA00820@devnull.Eng.Sun.COM>
Date: 4 Mar 91 16:24:54 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 50

Dale Luck writes:

> The company in questions, that has a package that will not work properly
> without backing store completely working in the server may have limited
> their potential market they certainly have not written 'buggy' code.
> Buggy code is code that has not taken care of unknown events or acts
> in unexpected ways. Their code is completely predictable in terms of
> the lack of backing store. They depend on it and when it is not there
> their code informs you. This is not buggy.
> 
First,  as I remember it the way they informed you of this was by
not redrawing part of the image,  causing the customer to phone their
support number to find out what was wrong.  That is buggy in anyone's terms.

Second,  even if they checked backing-stores in the connection handshake,
they would *still* not be able to depend on the presence of backing
store.  It is perfectly permissible for server to announce in the
connection handshake that it supports backing store but not to
provide it for a particular window,  or to provide it for a window
for some time and then stop providing it.  The value in the handshake
can tell you that the server *will not* provide backing store for a
window that has the hint,  but it cannot tell you that the server *will*
provide it.  To quote the protocol specification (page 383 of the Digital
Press 2nd edition):

	"Backing-stores indicates when the server supports backing stores
	for this screen,  although it may be storage limited in the
	number of windows it can support at once"

> Saying that the client should then do their own backingstore
> in this case by writing into a pixmap and displaying portions on the
> screen is wasteful and also wll produce the same result of not running
> since the same resources will be used up whether they are managed by
> the server (case of backing of store) or managed by the client (client
> side backing store).
> 
The difference is that the client will know up front whether the
alloc of the pixmap has succeeded,  and that the pixmap will not
thereafter be taken away.  The client has communicated to the
server that it is dependent on the resource.  Use of the backing
store hint tells the server that the client would like the
resource but isn't dependent on it.  These are semantically
different,  and the difference is useful information for the
server.  If you as a server implementor want to ignore this
information its your privilege.  But you cannot claim that
a client that announces to the server that it isn't dependent
on a resource when it actually is dependent on that resource
is correct.

	David.