jonnyg@ROVER.UMD.EDU (Jon Greenblatt) (12/03/87)
I have a temporary solution for those awaiting backing store. I found this very useful for me so I thought I'd share it. I am working on a image processing package that runs on X11 and needed some way to preserve and restore the image when it got abscured and needed this process to be automatic (sounds like backing store to me...). The way I simulated this was to create a pixmap the same size and depth of the window I was displaying and made this my background pixmap for the window (this will work in X10 on some servers). When ever I do a graphic command to the window I first do it to the background pixmap then to the window itself, the results are SIMULAR to backing store. For those of you who try this under X10, keep in mind that you can not execute graphics commands on a pixmap the way you can in X11. One thing to watch out for: you should paint the window and the background pixmap the same color before starting, the window is usualy white by default and the pixmap may be black or just garbage by default. By the way for those of you having problems with X11 image processing bugs, I put up the image by scan lines using vectors, I use points for vectors of lenght 1, they didn't show up otherwise. I have other reasons for using vectors instead of the image processing routines but thought I would throw this tidbit in anyway. Jon Greenblatt. (pcproj@gymble.umd.edu 128.8.128.16) (jonnyg@rover.umd.edu 128.8.2.73)
diamant@HPFCLP.SDE.HP.COM (John Diamant) (07/06/88)
> From: Robert Scheifler <RWS@zermatt.lcs.mit.edu> > Subject: Re: backing store > Date: Mon, 04 Jul 88 22:45:29 MDT > From: John Diamant <diamant@hpfclp.sde.hp.com> > 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
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (07/06/88)
It was a basic tenet of the X design that all clients must know how to repaint themselves. A corollary was that clients should not depend on backing-store. It is quite possible that a paint application would perform better if there was some way to tell the server "if you can give me backing-store, you must guarantee never to take it away" and to query if it gave it to you. (Although a paint program that relied completely on screen contents would be a pretty fragile thing.) I don't know how many other such clients there are. If you feel strongly about such support, you are encouraged to write up a proposal, and work through your X Consortium representatives to get it adopted.
pds@quintus.uucp (Peter Schachte) (07/07/88)
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
rob@daisy.UUCP (Rob Posadas) (07/08/88)
In article <156@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > >There's one thing I don't understand about the argument against allowing >programmers to insist on backing store. As I understand it, the > ... >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 > Why? Typically what is done is for the client to keep a display list of the objects that it has drawn on the screen. To refresh it runs through the display list and redraws each object. You shouldn't have to ask for a pixmap the size of the window unless you are implementing your own version of backing-store. >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. This would also make for a very complicated backing-store algorithm. The easiest implementation is to allocate a pixmap the size of the window as you suggested earlier. Then at a fairly high level in the server code, the server can just perform each output primitive twice. Once to the screen and one to the off-screen pixmap. It would always refresh from the off-screen pixmap and use the off-screen pixmap for XGetImage. If the server has to also maintain small pixmaps for just the occluded portion it would need the intelligence to run through a list of small pixmaps (remember, the window may be occluded in more than one place). What if you need to CopyArea from a piece that is in two small pixmaps and drop it on a piece that has has two other small pixmaps. Things start getting complicated very quickly. Whether or not it is all worth it is up to the individual server implementator. -- Rob Posadas -- Daisy Systems Corp 700 E. Middlefield Rd. Mt. View, CA 94039-7006 ucbvax!imagen!atari!daisy!rob
joel@pyr.gatech.EDU (Joel Rives) (02/11/89)
This may very well have come up in this discussion before. However, i have not been keeping up with the netnews traffic lately. Recently, i installed R3 on my Sun 3/60. I have also applied the patches from Purdue and compiled the server using gcc. The server works fine except for the case where Backing Store is made use of. In fact, Backing Store "works" fine. However, when destroying a widget hierarchy, wherein there are widgets which make use of Backing Store, the Server goes away, mysteriously. Does anyone have a clue as to what is going on here? I would appreciate any advice and/or patches that would help me solve this problem. joel -- The thief Left it behind-- The moon at the window. -Ryokan
keith@EXPO.LCS.MIT.EDU (Keith Packard) (02/11/89)
This bug is fixed in fix number 8, availible by mail from the xstuff server, "xstuff@expo.lcs.mit.edu". The release contains instructions on accessing the server, or send a message like To: xstuff@expo.lcs.mit.edu Subject: help You'll want to install all of the fixes, from 1 to 8 as there are some dependencies among them. Keith Packard MIT X Consortium (617) 253-1428 keith@EXPO.LCS.MIT.EDU
joel%pyr@GATECH.EDU (Joel Rives) (02/13/89)
Thanks for the information. I have pulled several fixes off of expo via ftp since the release of R3. Apparently, I haven't gotten this one yet. I'll take a look at it. Thanks again, joel
mlm@odi.com (Mitchell Model) (09/14/89)
[X11R3, 12mb Sun 3/60, OS 4.03, high-res monitor]
Having used other window systems which save the contents of obscured
windows (Smalltalk, various Lisp machines) I have been disconcerted by
my inability to get this feature working in X. Setting backing store
to WhenMapped in my application's windows results in strange behavior,
including displaying pieces of other windows.
First request: would someone who understands backing store in X
please give the rest of us an explanation of what it does, how it
works, and how to use it?
Yesterday, after a year of using X in several environments, I noticed
for the first time the -wm option to Xserver, which the man page
describes as follows:
-wm forces the default backing-store of all windows to
be WhenMapped; a cheap trick way of getting
backing-store to apply to all windows.
I tried starting up x with:
xinit -- -wm
and it worked just fine. The redisplay flash that otherwise occurs
when GNU Emacs is raised to the top doesn't happen, my application
doesn't get expose events when it is raised, etc. Looking at the SIZE
output of "ps avx", I can see that -wm is costing me a little less
than a megabyte, with several xterms, GNU Emacs running in an 81x75
window, my application (a structure graphics program for developing
object-oriented database schemata) in a 1500x1200 window, and a few
other things.
Second request: would people who have been using -wm please comment on
their experience. Is using -wm the norm? What are the drawbacks?
Etc. (Depending on those responses, if any, you could also interpret
this posting as sharing my discovery of -wm, which you might want to
try out.)
--
Mitchell L Model Object Design, Inc.
Director, HeadStart Program 1 New England Executive Park
Burlington MA 01803
mlm@odi.com, odi!mlm@uunet.uu.net (617) 270-9797rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/14/89)
Setting backing store
to WhenMapped in my application's windows results in strange behavior,
including displaying pieces of other windows.
Sounds like your server is not working properly. If you can reliably
reproduce the problems, submit a detailed bug report. I don't believe we've
seen any other reports like this.
First request: would someone who understands backing store in X
please give the rest of us an explanation of what it does, how it
works, and how to use it?
Sounds like you already understand this.
Second request: would people who have been using -wm please comment on
their experience. Is using -wm the norm? What are the drawbacks?
On a color display, it can bloat your server size dramatically. I used to
use -wm, but I don't any more. My server is fast enough ... :-)mlm@odi.COM (09/14/89)
Setting backing store
to WhenMapped in my application's windows results in strange behavior,
including displaying pieces of other windows.
Sounds like your server is not working properly. If you can reliably
reproduce the problems, submit a detailed bug report. I don't believe we've
seen any other reports like this.
I'll perform some further experiments....
First request: would someone who understands backing store in X
please give the rest of us an explanation of what it does, how it
works, and how to use it?
Sounds like you already understand this.
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), what I am really looking for is an "official" or
"recommended" way of selectively using backing store, both in raw Xlib
and in Xt (i.e., is one supposed to do anything other than act on the
XSetWindowProperties on XtWindow(widget)?). 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? 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? 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? 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?
On a color display, it can bloat your server size dramatically. I used to
use -wm, but I don't any more. My server is fast enough ... :-)
Yes, several people pointed out the greatly increased penalty paid on
a color monitor, although it's perhaps on a color monitor that one
stands to gain the most from backing store. Are there any
applications around that specify backing store because their response
to expose events is slow (or do applications like this generally
maintain their own internal pixmap for redisplay, scrolling, etc. --
another standard windowing technique that works in the absence of
backing store and also can provide superior scrolling behavior at the
cost of generating the entire image rather than just what fits within
the clipping region).
Thanks.
Mitchell L Model Object Design, Inc.
Director, HeadStart Program 1 New England Executive Park
Burlington MA 01803
mlm@odi.com, odi!mlm@uunet.uu.net (617) 270-9797mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (09/14/89)
> Having used other window systems which save the contents of obscured > windows (Smalltalk, various Lisp machines) I have been disconcerted > by my inability to get this feature working in X. Setting backing > store to WhenMapped in my application's windows results in strange > behavior, including displaying pieces of other windows. Sounds like a buggy server. > First request: would someone who understands backing store in X > please give the rest of us an explanation of what it does, how it > works, and how to use it? What does backing-store do? It asks (not tells) the server to keep a copy of the whole window so you don't have to regenerate portions of it yourself, just as you seem to expect it to. (I would have liked a way to say "this backing-store hint is not really a hint - give me an error if you can't commit to honoring it".) > [about the -wm option to someone's server] > Second request: would people who have been using -wm please comment > on their experience. Is using -wm the norm? Not around here. > What are the drawbacks? You pay the penalty for backing-store even on windows where it truly isn't necessary. I have a program, for example, that never draws anything in any window - all the display action happens by setting the background pixmaps of the windows. Backing-store would be wholly wasted on this program. You, as a programmer, also get the illusion that Expose events don't happen, so that code doesn't get tested. Then when run with a server that doesn't support -wm or was started without it, your program hiccups unexpectedly. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (09/14/89)
> 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
marbru@auto-trol.UUCP (Martin Brunecky) (09/17/89)
The server on DECstation 3100 claims it does both save_unders and backing_store (at least it returns values 1 and 2 to the query). However, when I display application that uses popup shells with save_under true, it does NOT save anything (I don't have this problem running to Sun-s running several flavors of servers). I understand that even though the server has the right to quit save_unders at any time, I don't see any reason why it's quitting on my 80x150 pixels popup, when it's the only application in 16MB system. Anyone with experience in save_unders and backing_store on DECstation ? -- ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru
dshr@eng.sun.COM (David Rosenthal) (03/05/91)
Dale Luck writes: > The company in questions, that has a package that will not work properly > without backing store completely working in the server may have limited > their potential market they certainly have not written 'buggy' code. > Buggy code is code that has not taken care of unknown events or acts > in unexpected ways. Their code is completely predictable in terms of > the lack of backing store. They depend on it and when it is not there > their code informs you. This is not buggy. > First, as I remember it the way they informed you of this was by not redrawing part of the image, causing the customer to phone their support number to find out what was wrong. That is buggy in anyone's terms. Second, even if they checked backing-stores in the connection handshake, they would *still* not be able to depend on the presence of backing store. It is perfectly permissible for server to announce in the connection handshake that it supports backing store but not to provide it for a particular window, or to provide it for a window for some time and then stop providing it. The value in the handshake can tell you that the server *will not* provide backing store for a window that has the hint, but it cannot tell you that the server *will* provide it. To quote the protocol specification (page 383 of the Digital Press 2nd edition): "Backing-stores indicates when the server supports backing stores for this screen, although it may be storage limited in the number of windows it can support at once" > Saying that the client should then do their own backingstore > in this case by writing into a pixmap and displaying portions on the > screen is wasteful and also wll produce the same result of not running > since the same resources will be used up whether they are managed by > the server (case of backing of store) or managed by the client (client > side backing store). > The difference is that the client will know up front whether the alloc of the pixmap has succeeded, and that the pixmap will not thereafter be taken away. The client has communicated to the server that it is dependent on the resource. Use of the backing store hint tells the server that the client would like the resource but isn't dependent on it. These are semantically different, and the difference is useful information for the server. If you as a server implementor want to ignore this information its your privilege. But you cannot claim that a client that announces to the server that it isn't dependent on a resource when it actually is dependent on that resource is correct. David.