Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!sun!quintus!pds
From: pds@quintus.uucp (Peter Schachte)
Newsgroups: comp.windows.x
Subject: Re: backing store
Summary: Why does backing store require more memory than not having it?
Message-ID: <156@quintus.UUCP>
Date: 6 Jul 88 21:32:28 GMT
References: <8807051918.AA21487@hpfcjrd.sde.hp.com> <19880705200523.3.RWS@KILLINGTON.LCS.MIT.EDU>
Sender: news@quintus.UUCP
Reply-To: pds@quintus.UUCP (Peter Schachte)
Organization: Quintus Computer Systems, Inc.
Lines: 24


There's one thing I don't understand about the argument against allowing
programmers to insist on backing store.  As I understand it, the
argument is that backing store requires too much memory for a
fixed-memory (no virtual memory) server to guarantee.  What confuses me
is that if I'm not guaranteed backing store, I have to ask for a pixmap
the size of the window, anyway.  And if I can't get it, my program is
going to abort.  So a fixed-memory server doesn't seem to be any worse
off by guaranteeing backing store.  I hope I haven't missed something
obvious.

Also, there's a good reason to supply guarenteed backing store:  memory
usage.  If I DON'T have guarenteed backing store, I'm going to go out
and allocate a pixmap big enough to back my entire window.  If I have
guaranteed backing store, the server doesn't need to use any memory to
back up the parts of the window that are visible.  Of course, when the
server guarentees me backing store, it has to set aside enough memory to
back up my entire window.  But a server that has fast and slow memory
(e.g., a hard disk) could set aside slow memory, but use fast memory to
back up small parts of my window when only a little of it is hidden.
This could make for better performance.

-Peter Schachte
pds@quintus.uucp
..!sun!quintus!pds