Xref: utzoo comp.misc:10438 comp.windows.x:28911
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.misc,comp.windows.x
Subject: Re: A tirade about inefficient software & systems
Message-ID: <1990Oct31.014133.14048@athena.mit.edu>
Date: 31 Oct 90 01:41:33 GMT
References: <9886@milton.u.washington.edu> <=YN6UN5@xds13.ferranti.com> <8460@scolex.sco.COM> <11R6593@xds13.ferranti.com> <1534@svin02.info.win.tue.nl> <P5S6=T1@xds13.ferranti.com>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Followup-To: comp.windows.x
Organization: Massachusetts Institute of Technology
Lines: 58


  (Note the Followup-To.)

In article <P5S6=T1@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes:
|> Even if it's at the other end of a 2400 baud SLIP link from the display
|> server?

  If you're running over a SLIP line, then you put "*backingStore: true" and
"*saveUnder: true" in your .Xresources file, and good clients will
automatically request backing-store and save-under on all windows as a result
of this, and good X servers will grant them.

  Note that X was not designed so that the X server *can't* store state.  It
was designed so that the X server *might* be able to serve state, and so that
clients can tell it whether or not this is an important requirement for them.

  As far as I know, all of the sample servers that come from MIT for X11R4 can
do backing-store and save-under, unless they're disabled explicitly when the X
server starts up.  Whether or not vendor X servers support backing-store and
save-under is the problem of the vendors.

|> It consumes just as much memory either way,

  Hogwash.  If the server is storing the contents of a window, it has to store
a pixmap of the entire window.  For a monochrome display, that's
1bitXwidthXheight, for a color, might be up to 32bitsXwidthXheight.

  On the other hand, very few X clients do refreshing by storing a complete
pixmap of the window.  Xterm, for example, only needs to store the characters
it needs to draw, i.e. 8bitsXcharacter-widthXcharacter-height.  Most graphics
programs only store the attributes of the shapes that have been drawn, so that
they can be redrawn when a refresh events come in.

  Unless an application stores a full pixmap, the memory required for an
application to store window state is far less than the memory required for the
server to store window state.

|> and it requires the client
|> be able to respond in real-time... something that's just plain not
|> possible in UNIX.

  It requires the clients to be able to respond in a reasonable amount of
time.  Funny, I never noticed any problem with X just because the clients
can't "respond in real-time", and I work under it almost exclusively, without
backing-store and save-under on my windows.

|> It makes as much sense to have "xman" handle update
|> events as it does to have "cat" do erase and kill processing.

  Fiddlesticks.  It's more efficient memory-wise, and where other problems
make it less efficient (e.g. the 2400 baud SLIP you mentioned above), it's
possible to get the server to do it.  So you win either way.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710