Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!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: <9103060625.AA06351@lightning.McRCIM.McGill.EDU>
Date: 6 Mar 91 06:25:17 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 56

> So they [clients] now do there [sic] 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.

Yup, that's the price the user pays for trying to second-guess programs
about the usefulness of backing-store for their windows.

> 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.

I would not say *nothing* wrong.  It is an entirely self-consistent
point of view, I suppose.  However, when the program is sold as an X
program, there is the implication that it runs on an X server.  And X
servers are permitted to drop backing-store at any time, for any
reason.  If the product requires an X-plus-guaranteed-backing-store
server, it should be up-front about it.  While I have not seen the
marketing propaganda for the product in question, I have no doubt it
does not mention anything of the sort.  (Would whoever posted the
original message care to check and tell me?)

>> If we had been prepared to *require* the server to maintain backing
>> store for windows and [...], [we'd have a design] [...] which would
>> have consumed much more resource[s].  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.

And, of course, the Amiga windowing system and X are identical in all
other respects.  Riiiight.  (I actually think dshr wasn't talking about
code space size as much as run-time memory usage.)

Have you looked at how complicated it would be to add a Guaranteed
backing-store "hint" value?  I haven't.  I doubt you have; if you have,
please correct me and I'll shut up.  Until then, I think we should both
take the word of someone who can be presumed to know what he[%]'s
talking about....

[%] "David" seems to imply "he" rather strongly :-)

					der Mouse

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