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