daniel@mirsa.inria.fr (Daniel Dardailler) (01/02/90)
From the Red Bible:
"If save-under is True, the X server is advised that, when this window
is mapped, saving the contents of windows it obscures would be beneficial."
It seems that the good interpretation is:
... saving the *entire* contents of the windows it obscures ...
[setting all the obscured windows' backing-store flags temporarily ON]
and the bad interpretation was:
... saving the *partial* contents of the windows it obscures ...
[saving the part of the screen under the save-under window]
My question is: Why?
Since my application requires me to create huge windows (together with
clip and coordinate translation features), the only way I can be sure
that X doesn't gobble up memory is to use an X server that has been
started with the -bs option...
Daniel Dardailler | Email : daniel@mirsa.inria.fr
BULL Centre de Sophia Antipolis | Phone : (33) 93 65 77 71
2004, Route des Lucioles | Telex : 97 00 50 F
06565 Valbonne CEDEX France | Fax : (33) 93 65 77 66
|rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (01/03/90)
It seems that the good interpretation is:
...
and the bad interpretation was:
No, you have it backwards. Perhaps the sample server has you confused,
since it implements the less desirable interpretation. It does this
because it was expedient, and fixing other things was higher on our
priority list. It is still on our list of things to fix.mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (01/06/90)
> From the Red Bible: > "If save-under is True, the X server is advised that, when this > window is mapped, saving the contents of windows it obscures would > be beneficial." > It seems that the good interpretation is: > ... saving the *entire* contents of the windows it obscures ... > [setting all the obscured windows' backing-store flags temporarily ON] > and the bad interpretation was: > ... saving the *partial* contents of the windows it obscures ... > [saving the part of the screen under the save-under window] > My question is: Why? I don't *know*, not being responsible for the decision. However, I would guess that it's simply because doing the latter and getting it right is very difficult. [Terminology: call the window whose save-under hint is set the "menu" window; call the window being temporarily obscured the "obscured" window. I will speak of "the" obscured window even though there may be more than one such. An obscured window for which the server is already maintaining backing-store can of course be ignored.] Suppose the temporarily hidden part of the obscured window is changed while the menu window is up. The saved bits then have to be updated, which is very difficult to get right without maintaining a shadow copy, which is precisely what backing-store does. You're losing because backing-store maintains a shadow copy of more than just the area hidden by the menu window. (Personally, I'd be just as happy to see a much simpler and almost as good version: save the bits as in the "bad" interpretation above, but if an obscured window is changed, clear its portion of the save array to its background color and then generate expose events for that window when the menu window goes away, just as if save-unders weren't being used. Gains the speed advantage in the common case and is correct, even though slower, in the difficult case. And it's not a memory pig in the case that bothered you.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
marbru@auto-trol.UUCP (Martin Brunecky) (01/08/90)
In article <9001061202.AA18171@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) writes: > >Suppose the temporarily hidden part of the obscured window is changed >while the menu window is up. The saved bits then have to be updated, >which is very difficult to get right without maintaining a shadow copy, >which is precisely what backing-store does. You're losing because >backing-store maintains a shadow copy of more than just the area hidden >by the menu window. > >(Personally, I'd be just as happy to see a much simpler and almost as >good version: save the bits as in the "bad" interpretation above, but >if an obscured window is changed, clear its portion of the save array >to its background color and then generate expose events for that window >when the menu window goes away, just as if save-unders weren't being >used. Gains the speed advantage in the common case and is correct, >even though slower, in the difficult case. And it's not a memory pig >in the case that bothered you.) > ... and in my opinion, this would very well justify the distinction between "save_under" and "backing_store"; i.e. save_under ... attempts to preserve obscured area as long as there is no attmpt to change this area backing_store ...makes sure the server maintains the entire window no matter how much of it is obscured or invisible [ however, the statement that the server can "give up" on any of the both features is still valid, i.e. even backing store does NOT guarantee window integrity under ALL circumstances ] The "lightweight" save-under implementation would serve it's principal purpose: reduce (not eliminate) the amount of expose event generated by popup shells (or any transient in nature windows). -- ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru