Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uunet!olivea!oliveb!amiga!boing!dale
From: dale@boing.UUCP (Dale Luck)
Newsgroups: comp.windows.x
Subject: Re: PC X servers / backing store
Message-ID: <952@boing.UUCP>
Date: 4 Mar 91 21:51:55 GMT
References: <9103032356.AA00215@devnull.Eng.Sun.COM>
Reply-To: dale@boing.UUCP (Dale Luck)
Organization: Boing, Milpitas, Ca.
Lines: 79

In article <9103032356.AA00215@devnull.Eng.Sun.COM> dshr@eng.sun.COM (David Rosenthal) writes:
>> >> A problem encountered with both products is that if a graphics window
>> >> is overlaid ( e.g. by a menu ), the overlaid portion is not restored.
>> >> 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.
>
>Sorry,  but backing store is not a feature like colors or visuals.

If I'd known you were going to post this as well as email me your response
I would have posted my response as well, now I have to dig it up from
memory. :-)

>It is a *hint* to the server,  which the server is at liberty to
>ignore at any time for any reason.  To quote from the protocol
>specification (page 388 of the Digital Press 2nd edition):
>
>The package in question,  and any other X program that *depends* on
>not getting exposure events from windows with backing store,  and any X
>program that *depends* on the save-under hint being observed,  is indeed
>buggy.  Its OK to work better if you don't get the exposure events; its
>not OK to break if you do.

But they do not break. They inform you that you have a server-system that is
not up to the task of supporting this application.  If the complexities of
output generation mean that it takes an inordinate amount of time to regen
the display except on a CRAY then refreshing via a display list is out of
the question.
Whats the alternative? You have to depend on a raster image to maintain
it's contents. Most of the servers out there have backing store built in
and can deal with automatic saving and recovery of the pixels. This typically
requires additional resources on the server end, in particular memory.
If the application is required to maintain the backing pixmap, guess what?
The same resources get chewed too. So what should the application now
do if those resources are chewed up and it has been a good citizen managing
it's own backing store? Well I guess it loses the information there as well.
So now let's say the server does do backing store but the client can depend on
it? So they now do there own backing store, but the user has requested that
all windows have backing store and we see that the server now wastes backing
store bits on a window that is doing its own backing store. So when that window
goes behind all others we see the server eating twice as much memory for that
window.

IMHO, there is nothing wrong with a decision by a company to specify
that the servers that are used to display their application must have a
working backing store implementation as well as enough resources(memory) to
insure that the bits do not get lost during standard operation of the program.
These are prerequisites for running this application.

>This is a very important point to understand.  If we had been prepared to
>*require* the server to maintain backing store for windows and to make
>a number of other similar decisions during the design of X,  we would have
>ended up with a completely different design which would have
>been faster and simpler but which would have consumed much more resource.
>It would,  for example,  have been improbable that an X-terminal or a
>PC X-server would have been a viable product had we taken this route.

I couldn't agree with you less on this last statement. Case in point:
The Amiga guarentees backing store with it's SMART_REFRESH windows.
The programmer is able to choose whether they can handle expose
events or not. SIMPLE_REFRESH windows always generate expose events
whenever it is uncovered. SMART_REFRESH windows do not.
If the Amiga was able to do this in a 16k layer library and a 64k
graphics library (nearly all written in C) then it could be done
in the X Window system as well.

>
>	David.


-- 
Dale Luck     GfxBase/Boing, Inc.
{uunet!cbmvax|pyramid}!amiga!boing!dale