Path: utzoo!attcan!uunet!lll-winken!brutus.cs.uiuc.edu!usc!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  backing store
Message-ID: <8909140221.AA18193@Larry.McRCIM.McGill.EDU>
Date: 14 Sep 89 02:21:39 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 72

> I should have been more explicit: in addition to a clear general
> description (and there several ways backing store can be implemented
> in a window system, including having each window save the bits that
> IT obscures),

I suppose it could be done this way, but it would be messy.  Barring
bugs and things beyond the control of X (like another program
scribbling on the raw display), the only effect of backing-store is to
reduce the quantity of Expose events generated.  This is usually done
by having every window keep an off-screen copy of its contents.  The
technique you mention could be used, but keeping everything consistent
when an obscured part of a window is drawn into or a partially obscured
window is moved (to mention just two cases) would be a real circus.

What you seem to be thinking of is what X calls save-unders.

> Is it OK to turn backing store on in the middle of things, perhaps
> even after the initial expose event, or must it be set before the
> window is mapped?

As far as I can tell, the backing-store hint of a window can be changed
at any time.  The server is free to ignore the hint if it feels like
it, for any reason or none (this is part of the spec, and "ignore the
hint" can mean either or both of "keep backing-store when not
requested" and "don't keep backing-store even though requested").

> What about window parents/children -- must they all have
> backing_store to get a desired effect, or is setting it for the
> application's top-window sufficient?

My reading of the documentation is that each window has its own
backing-store hint, which is unaffected by the backing-store hint of
its parent or hints of any of its children.

> I can't make sense out of backing_pixel, documented in "X Window
> System" as "value to use in restoring planes", page 32; shouldn't
> backing store record the value of each pixel in the image being saved
> (i.e., the binary value at each position of each plane?)?  Why is a
> pixel necessary, and what kind of value should it be given?

The documentation I have is somewhat unclear.  All of the following is
my idea of what's supposed to happen, based on reading the
documentation and guessing at what would be reasonable to do.  It may
well be wrong, so don't take it as gospel.

What I think backing_pixel is intended to do is to provide a value for
pixels that aren't saved in backing-store (regardless of the reason: no
backing-store requested, or the server ignoring the rqeuest).  That is,
if you have a window with no backing-store, and part of it is obscured
and then exposed, the newly exposed area will be filled with pixels
whose color is the backing_pixel of the window.

The backing_pixel is also used if backing-store is enabled but
backing_planes is not set to ~0.  In this case, if a pixel of color p
is to be saved in backing-store, what is saved is p&backing_planes, and
when exposing, what is displayed is
(p&backing_planes)|(backing_pixel&~backing_planes).

> If backing store is just a window property, then I suppose one could
> write an application along the lines of xwininfo that turned backing
> store on for a designated window (by name or by pointing); anything
> wrong with that idea?

Only that it seems somehow inappropriate to try to decide that you know
better than the application author, who presumably has provided a
reasonable backing-hint for the application.  I see no technical
problem with it, though doubtless others will point some out.

					der Mouse

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