Path: utzoo!attcan!uunet!husc6!bloom-beacon!HPFCLP.SDE.HP.COM!diamant From: diamant@HPFCLP.SDE.HP.COM (John Diamant) Newsgroups: comp.windows.x Subject: Re: backing store Message-ID: <8807051918.AA21487@hpfcjrd.sde.hp.com> Date: 5 Jul 88 19:18:35 GMT References: <19880705150956.9.RWS@KILLINGTON.LCS.MIT.EDU> Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 34 > From: Robert Scheifler> Subject: Re: backing store > Date: Mon, 04 Jul 88 22:45:29 MDT > From: John Diamant > Servers do tell you up front (see Xlib's XDoesBackingStore and > XDoesSaveUnders) whether they implement backing-store and save-unders at > all. This is probably an adequate indication for most clients; if a > server says it implements the functionality, it probably will do what > you ask for most windows. You should assume the server will maintain > contents until you get an exposure event that contradicts it, and only > then start maintaining a client-side shadow if that will increase > performance. I'm not sure this is possible in some applications. For instance, a paint program may want to rely on the server maintaining its image, and when it's ready to write the output, it could grab the server (or whatever was required to ensure no window got placed on top of it) and read the bits back off the screen. If somewhere in the middle of all this painting, the server suddenly decided it couldn't handle the backing store, then the application is in trouble, since it didn't maintain the information itself. In the current scenario, it would still be required to maintain a backup copy and duplicate all the work of the server. With a little more information from the server, it wouldn't be required to do that (this all assumes the paint program did not maintain a complete history of user commands to reproduce the image some other way). John Diamant Software Development Environments Hewlett Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant