fsg@ucthpx.uct.ac.za (Fred S. Goldstein) (02/19/91)
I have been running some initial tests with two PC X server products: PC-XSIGHT and TEAMTALK-X ( a repackaged HCl-eXceed Plus ). The client software I am using is GRAFIT running on an HP 9000/825. A problem encountered with both products is that if a graphics window is overlaid ( e.g. by a menu ), the overlaid portion is not restored. The suppliers of Grafit informed me that the X server implementation probably did not support backing store - a requirement for their package ( or for the HP Starbase/X implementation? ). I have just received a third test package - XVISION - and the documents state that it, too, does not support backing store. Does anyone know of a PC X server product that supports backing store?? -- Fred Goldstein ( fsg@ucthpx.uct.ac.za ) University of Cape Town
ckp@grebyn.com (Checkpoint Technologies) (03/02/91)
In article <1991Feb19.152725.24673@ucthpx.uct.ac.za> fsg@ucthpx.uct.ac.za (Fred S. Goldstein) writes: >The suppliers of Grafit informed me that the X server implementation >probably did not support backing store - a requirement for their >package ( or for the HP Starbase/X implementation? ). (Not the answer you're looking for, I know, but...) You should tell the authors of Grafit that the program is flawed and should be fixed. If it only works with backing store then it's not a good X client. IMHO. Sure, the program is designed to run on a particular workstation, and they might know that vendor's X has backing store. But what if backing store becomes exhausted? It can. And since X is a networked system, then just because the program's running on the workstation there's no telling what display device, of the entire range of possible commercial or private options, is presenting the display. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
mouse@lightning.mcrcim.mcgill.EDU (03/02/91)
> The client software I am using is GRAFIT running on an HP 9000/825. > A problem encountered with both products is that if a graphics window > is overlaid ( e.g. by a menu ), the overlaid portion is not restored. > The suppliers of Grafit informed me that the X server implementation > probably did not support backing store - a requirement for their > package ( or for the HP Starbase/X implementation? ). Then their package is buggy. X programs must *always* be prepared to deal with Expose events! If they *must* have backing-store-style semantics, then they should arrange their own pseudo-backing-store. For example, they might create a pixmap and use it to handle exposures. This is a mildly bad idea (pixmap memory may be a precious resource), but is certainly a better idea than breaking if the server doesn't choose to maintain backing-store! Who are "[t]he suppliers of Grafit"? I want to know who to avoid.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dale@boing.UUCP (Dale Luck) (03/03/91)
In article <9103020232.AA05738@lightning.McRCIM.McGill.EDU> mouse@lightning.mcrcim.mcgill.EDU writes: >> The client software I am using is GRAFIT running on an HP 9000/825. > >> A problem encountered with both products is that if a graphics window >> is overlaid ( e.g. by a menu ), the overlaid portion is not restored. >> The suppliers of Grafit informed me that the X server implementation >> probably did not support backing store - a requirement for their >> package ( or for the HP Starbase/X implementation? ). > >Then their package is buggy. This is absolutely untrue. Backing store is a feature just like colors, visuals, shape extensions, pex and everything else. There is nothing wrong with a package requiring properly working backstore for that package to work. The graphics that are being generated maybe entirely to complex to redraw efficiently if an expose event occurs. I can think of just about any ray tracing program that would have that problem. Also most raster paintprograms are not really in the mood to have to retrace all the users steps to recreate a particular image every time a menu pops up on the drawable and the server goes oops. Saying that the clients should do it's own backing store if the xserver can't do it is like saying the client should map colors to dither patterns if it sees a b/w color terminal, or automatically scale a drawing down if the terminal's resolution is not large enough to present a satisfactory Sure these are nice things to have but sometimes the resulting product in such a degraded state on a X server that just does not have the right capabilities is just a waste of programmer effort. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
russell@spdcc.COM (Tim Russell) (03/03/91)
In article <1991Mar2.011210.21219@grebyn.com> ckp@grebyn.com (Checkpoint Technologies) writes: >In article <1991Feb19.152725.24673@ucthpx.uct.ac.za> fsg@ucthpx.uct.ac.za (Fred S. Goldstein) writes: >>The suppliers of Grafit informed me that the X server implementation >>probably did not support backing store - a requirement for their >>package ( or for the HP Starbase/X implementation? ). > >(Not the answer you're looking for, I know, but...) > >You should tell the authors of Grafit that the program is flawed and >should be fixed. If it only works with backing store then it's not a >good X client. IMHO. In anybody's O, I should hope.. Instead of looking at paying large sums of money for another client, you should be screaming bloody murder at the Grafit people for releasing such a shoddy product. Backing store fills up, and regardless, you shouldn't be forced into having to pay more for a system that supports it (especially once AT&T starts their licensing :-)) simply because they're too lazy to write code for redrawing. -- ____ \TR/ Tim Russell \/ russell@ursa-major.spdcc.com
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/03/91)
>>> The suppliers of Grafit informed me that the X server >>> implementation probably did not support backing store - a >>> requirement for their package ( or for the HP Starbase/X >>> implementation? ). >> Then their package is buggy. > This is absolutely untrue. Backing store is a feature just like > colors, visuals, shape extensions, pex and everything else. There is > nothing wrong with a package requiring properly working backstore for > that package to work. There is nothing improper about a backing-store implementation that doesn't always maintain a backing image. The server is - and always has been - permitted to stop maintaining backing-store at any time, for any reason (such as running short of memory). Perhaps there should have been another value for the backing-store hint that says "I want backing-store, and I want an error if you can't commit to it", but there isn't. > The graphics that are being generated maybe entirely to complex to > redraw efficiently if an expose event occurs. That's what I meant about "if they must have backing-store style semantics". Yes, there is a large class of programs for which it is impractically expensive to regenerate the image; such programs should maintain their own store, either in a pixmap on the server or in an image on the client. > Saying that the clients should do it's own backing store if the > xserver can't do it is like saying the client should map colors to > dither patterns if it sees a b/w color terminal, (What, pray tell, is a "b/w color terminal"?) > or automatically scale a drawing down if the terminal's resolution is > not large enough to present a satisfactory (A satisfactory *what*?) Yes, you could look at it that way. I prefer to look at it more along the lines of requiring the server to maintain backing-store is like requiring the screen to be 1152x900: it is unreasonable. Sure, you can write a program that works only on servers that have 95 keys and a screen of 1120x832 pixels. I would call such a program buggy just as fast as I would one that demands backing-store. > Sure these are nice things to have but sometimes the resulting > product in such a degraded state on a X server that just does not > have the right capabilities is just a waste of programmer effort. Certainly. But some things are unreasonable to demand. I think the demand under discussion is unreasonable. Clients have always been required to handle Expose events; why should this change now? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dshr@eng.sun.COM (David Rosenthal) (03/04/91)
> >> A problem encountered with both products is that if a graphics window > >> is overlaid ( e.g. by a menu ), the overlaid portion is not restored. > >> The suppliers of Grafit informed me that the X server implementation > >> probably did not support backing store - a requirement for their > >> package ( or for the HP Starbase/X implementation? ). > > > >Then their package is buggy. > This is absolutely untrue. Backing store is a feature just like colors, > visuals, shape extensions, pex and everything else. There is nothing > wrong with a package requiring properly working backstore for that > package to work. Sorry, but backing store is not a feature like colors or visuals. It is a *hint* to the server, which the server is at liberty to ignore at any time for any reason. To quote from the protocol specification (page 388 of the Digital Press 2nd edition): "A backing-store of WhenMapped advises the server that maintaining contents of obscured regions when the window is mapped would be benficial. A backing store of Always advises the server that maintaining contents even when the window is unmapped would be beneficial. ... While the server maintains contents, exposure events will not normally be generated, but the server may stop maintaining contents at any time." Note the "advises ... would be beneficial" wording, the note that exposure events "will not normally be generated", and the explicit warning that the server may stop maintaining contents at any time. The package in question, and any other X program that *depends* on not getting exposure events from windows with backing store, and any X program that *depends* on the save-under hint being observed, is indeed buggy. Its OK to work better if you don't get the exposure events; its not OK to break if you do. This is a very important point to understand. If we had been prepared to *require* the server to maintain backing store for windows and to make a number of other similar decisions during the design of X, we would have ended up with a completely different design which would have been faster and simpler but which would have consumed much more resource. It would, for example, have been improbable that an X-terminal or a PC X-server would have been a viable product had we taken this route. David.
mikel@teda.UUCP (Mikel Lechner) (03/04/91)
dale@boing.UUCP (Dale Luck) writes: >This is absolutely untrue. Backing store is a feature just like colors, >visuals, shape extensions, pex and everything else. There is nothing >wrong with a package requiring properly working backstore for that [. . .] Very wrong. Read the documentation. It says very clearly that backing store is an optional feature provided by X servers. It is merely a hint to the X server the backing store would be useful to the application. X servers are not required to support it. All applications should be prepared to handle expose events in the event that backing store is not available. I can understand the desire for backing store in computationaly significant graphics applications, but not designing an X application to handle the situation without backing store is a design flaw IMHO. -- Mikel Lechner UUCP: teda!mikel Teradyne EDA, Inc. 5155 Old Ironsides Drive | If you explain so clearly that nobody Santa Clara, Ca 95054 | can misunderstand, somebody will.
melby@pappa.yk.fujitsu.co.jp (John Melby) (03/04/91)
Er...I believe that the documentation on backing store states clearly that it is only provided _when the server decides to provide it_. Thus, any sensible program should handle expose events, in case the server prefers not to allocate it (or has to be modified so that it will not allocate it ;-) ). ----- John B. Melby Fujitsu Limited, Machida, Japan melby%yk.fujitsu.co.jp@uunet
tim@dell.co.uk (Tim Wright) (03/04/91)
In <1991Mar2.011210.21219@grebyn.com> ckp@grebyn.com (Checkpoint Technologies) writes: >In article <1991Feb19.152725.24673@ucthpx.uct.ac.za> fsg@ucthpx.uct.ac.za (Fred S. Goldstein) writes: >>The suppliers of Grafit informed me that the X server implementation >>probably did not support backing store - a requirement for their >>package ( or for the HP Starbase/X implementation? ). >(Not the answer you're looking for, I know, but...) >You should tell the authors of Grafit that the program is flawed and >should be fixed. If it only works with backing store then it's not a >good X client. IMHO. Entirely correct. You *CANNOT* rely on the server giving you backing store for a particular window even if the server says it supports backing store. X11R3 does not have the facility at all. On a tangent, how long before the X server puts up a dialog box asking for your credit card number to pay AT&T if you want to use backing store at all :-(. (AT&T are claiming a patent on the use of backing store in a windowing system. If you think this is ridiculous, join the League for Programming Freedom). Tim -- Tim Wright, Dell Computer Corp., Bracknell | Domain: tim@dell.co.uk Berkshire, UK, RG12 1RW. Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim Nobody ever said I was charming before. They said, "Rimmer, you're a total git" - Red Dwarf, "Camille".
marbru@attc.UUCP (Martin Brunecky) (03/04/91)
In article <9103032356.AA00215@devnull.Eng.Sun.COM> dshr@eng.sun.COM (David Rosenthal) writes: >> > >> >Then their package is buggy. >> This is absolutely untrue ..... > >Sorry, but backing store is not a feature like colors or visuals. >It is a *hint* to the server ...... > >The package in question, and any other X program that *depends* on >not getting exposure events from windows with backing store, and any X >program that *depends* on the save-under hint being observed, is indeed >buggy. Its OK to work better if you don't get the exposure events; its >not OK to break if you do. > My $.01. The word *depends* should be applied in two different contexts: 1) Functionality: Application that *depends* on backing store to *function* is definitely buggy, as even the best implementation of backing store has the right to quit - even may be once in 1 million cases. 2) Performance: Application that *depends* on backing store to *perform* acceptably is most likely correct. You don't run the Finite Element Analysis for F-119 on an 8086 PC. Similarly, you don't run an application which is a heavy user of backing store (or save-unders) on something that does not support it sufficiently. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
dvb@emisle.uucp (David Van Beveren) (03/05/91)
In article <21619@teda.UUCP> mikel@teda.UUCP (Mikel Lechner) writes: >dale@boing.UUCP (Dale Luck) writes: > >>This is absolutely untrue. Backing store is a feature just like colors, >>visuals, shape extensions, pex and everything else. There is nothing >>wrong with a package requiring properly working backstore for that [. . .] > >Very wrong. Read the documentation. It says very clearly that backing >store is an optional feature provided by X servers. It is merely a hint >to the X server the backing store would be useful to the application. >X servers are not required to support it. All applications should be >prepared to handle expose events in the event that backing store is not >available. > >I can understand the desire for backing store in computationaly significant >graphics applications, but not designing an X application to handle the >situation without backing store is a design flaw IMHO. I agree with both of you. First, all programs should not require backing store in the server to operate correctly. The need to redraw complicated graphics can be alleviated by using a technique involving drawing to a pixmap and using XCopyArea to handle exposures. Therefore, not supporting an exposure event is a definite DESIGN FLAW. However, as to a certain diminuitive rhodent who asserts it is a BUG, I disagree. I believe that any program that does not support resizing is flawed. But, I would not call that a bug, rather a design deficiency. There is a BIG difference. Let's just say it is a BAD thing rather than a bug. A bug is something that the programmer does not understand that is causing the program to do things in unexpected fashion. Even once a bug is found, and understood, it still has the attribute of being uncalled for in the design. This exposure thing sounds like it was in the design. I call that a bad design, not a bug. Is my verbosity saying it all? -- David Van Beveren INTERNET: emisle!dvb@ism.isc.com EIS ltd. Professional Software Services UUCP: ..uunet!emisle!dvb voice: (818) 587-1247
ekberg@asl.dl.nec.COM (Tom Ekberg) (03/05/91)
From: boing!dale@bloom-beacon.mit.edu (Dale Luck) > This is absolutely untrue. Backing store is a feature just like colors, > visuals, shape extensions, pex and everything else. ... I have do disagree with that. From the X11R4 protocol document: 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. If save-unders is True, the server can support the save-under mode in CreateWindow and ChangeWindowAttributes, although again it may be storage limited. This means that backing store may be supported by a server, and that a server that supports it may choose to not honor advice that it should maintain the contents of obscured regions when the window is mapped. Checking to see if the server supports backing store via the macro DoesBackingStore(screen) is not enough. The same is true for save-unders and the DoesSaveUnders(screen) macro. As was stated earlier, X clients should always be prepared to handle expose events. -- tom, ekberg@aslss02.asl.dl.nec.com (x3503)
bill@polygen.uucp (Bill Poitras) (03/05/91)
In article <1991Feb19.152725.24673@ucthpx.uct.ac.za> fsg@ucthpx.uct.ac.za (Fred S. Goldstein) writes: >A problem encountered with both products is that if a graphics window >is overlaid ( e.g. by a menu ), the overlaid portion is not restored. >The suppliers of Grafit informed me that the X server implementation >probably did not support backing store - a requirement for their >package ( or for the HP Starbase/X implementation? ). > Just for your information, what you just described above is not backing store but save unders. Backing store works when anything BUT a menu which obscures another window is moved so the current window is exposed. >I have just received a third test package - XVISION - and the documents >state that it, too, does not support backing store. > >Does anyone know of a PC X server product that supports backing store?? Yes. Try PC-Xview from Spectragraphics/Graphics Software Systems. The current version is 2.1. The EGA/VGA version of the server supports backing store. The DGIS version doesn't. According to GSS, PC-Xview 2.2 will support backing store in its DGIS version. It it due out sometimes after the end of March. GSS can be reached at (503)641-2200. Let me know if you have any other questions about this server. It is the best I have seen so far. I have PC-Xsight, PC-Xview, X11/AT, and XVision. +-----------------+---------------------------+-----------------------------+ | Bill Poitras | Polygen Corporation | {princeton mit-eddie | | (bill) | Waltham, MA USA | bu sunne}!polygen!bill | | | FAX (617)890-8694 | bill@polygen.com | +-----------------+---------------------------+-----------------------------+
dale@boing.UUCP (Dale Luck) (03/05/91)
In article <9103032356.AA00215@devnull.Eng.Sun.COM> dshr@eng.sun.COM (David Rosenthal) writes: >> >> A problem encountered with both products is that if a graphics window >> >> is overlaid ( e.g. by a menu ), the overlaid portion is not restored. >> >> The suppliers of Grafit informed me that the X server implementation >> >> probably did not support backing store - a requirement for their >> >> package ( or for the HP Starbase/X implementation? ). >> > >> >Then their package is buggy. >> This is absolutely untrue. Backing store is a feature just like colors, >> visuals, shape extensions, pex and everything else. There is nothing >> wrong with a package requiring properly working backstore for that >> package to work. > >Sorry, but backing store is not a feature like colors or visuals. If I'd known you were going to post this as well as email me your response I would have posted my response as well, now I have to dig it up from memory. :-) >It is a *hint* to the server, which the server is at liberty to >ignore at any time for any reason. To quote from the protocol >specification (page 388 of the Digital Press 2nd edition): > >The package in question, and any other X program that *depends* on >not getting exposure events from windows with backing store, and any X >program that *depends* on the save-under hint being observed, is indeed >buggy. Its OK to work better if you don't get the exposure events; its >not OK to break if you do. But they do not break. They inform you that you have a server-system that is not up to the task of supporting this application. If the complexities of output generation mean that it takes an inordinate amount of time to regen the display except on a CRAY then refreshing via a display list is out of the question. Whats the alternative? You have to depend on a raster image to maintain it's contents. Most of the servers out there have backing store built in and can deal with automatic saving and recovery of the pixels. This typically requires additional resources on the server end, in particular memory. If the application is required to maintain the backing pixmap, guess what? The same resources get chewed too. So what should the application now do if those resources are chewed up and it has been a good citizen managing it's own backing store? Well I guess it loses the information there as well. So now let's say the server does do backing store but the client can depend on it? So they now do there own backing store, but the user has requested that all windows have backing store and we see that the server now wastes backing store bits on a window that is doing its own backing store. So when that window goes behind all others we see the server eating twice as much memory for that window. IMHO, there is nothing wrong with a decision by a company to specify that the servers that are used to display their application must have a working backing store implementation as well as enough resources(memory) to insure that the bits do not get lost during standard operation of the program. These are prerequisites for running this application. >This is a very important point to understand. If we had been prepared to >*require* the server to maintain backing store for windows and to make >a number of other similar decisions during the design of X, we would have >ended up with a completely different design which would have >been faster and simpler but which would have consumed much more resource. >It would, for example, have been improbable that an X-terminal or a >PC X-server would have been a viable product had we taken this route. I couldn't agree with you less on this last statement. Case in point: The Amiga guarentees backing store with it's SMART_REFRESH windows. The programmer is able to choose whether they can handle expose events or not. SIMPLE_REFRESH windows always generate expose events whenever it is uncovered. SMART_REFRESH windows do not. If the Amiga was able to do this in a 16k layer library and a 64k graphics library (nearly all written in C) then it could be done in the X Window system as well. > > David. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
graeme@krite.labtam.oz (Graeme Gill) (03/05/91)
> "A backing-store of WhenMapped advises the server that maintaining > contents of obscured regions when the window is mapped would be > benficial. A backing store of Always advises the server that > maintaining contents even when the window is unmapped would be > beneficial. ... While the server maintains contents, exposure > events will not normally be generated, but the server may stop > maintaining contents at any time." I vaguely remember seeing a discussion about this recently somewhere, but could someone throw some light on why setting backing store to "always" as opposed to "not useful" or "when mapped" breaks many clients written in the standard fashion. What seems to happen is that since the backing pixmap is created on window creation, then raising the window doesn't generate an expose, so the client never draws anything to the window. In other words, the server seems to go to extremes in avoiding sending expose events to the client, to the point where it is not initialising the backing pixmap ! This seems like a bug in the server backing store code. Is this behavior supported so that a client that sees that backing store is always enabled can assume it will never get an expose event, and that it is ok to draw to the window prior to raising it ? This seems contrary to the quoted protocol section above. Correct behavior should be to send an expose event to initialise any un-initialised portion of the backing store pixmap, whenever the window is raised. (This would be to prevent breaking any clients that only expect expose events when the window is raised.) This would also cope properly with a situation in which memory for the backing store pixmap becomes available sometime after a client has started. The backing store could be assumed to have been initialised if written to prior to being raised. Graeme Gill Labtam Australia Pty. Ltd. graeme@labtam.oz.au
rws@expo.lcs.mit.EDU (Bob Scheifler) (03/05/91)
could someone throw some light on why setting backing store to "always"
as opposed to "not useful" or "when mapped" breaks many clients written
in the standard fashion.
Because the exposure event is generated when the window is created, and
many applications don't select for events as part of CreateWindow, they
select for events in a separate protocol request. At least, this is what
happens in a correct server. It's possible you are using a broken server
that fails to generte exposure events at create time. Note that if you
mean you are using some kind of server config option to force Always on
unsuspecting clients, this is contrary to the specification, so you
shouldn't be surprised if clients break. WhenMapped is the strongest
implicit default you can force on clients.
Correct behavior should be to send an expose event to initialise
any un-initialised portion of the backing store pixmap, whenever the window
is raised.
Nope. Read the protocol spec (CreateWindow, para 12).dshr@eng.sun.COM (David Rosenthal) (03/05/91)
> Correct behavior should be to send an expose event to initialise > any un-initialised portion of the backing store pixmap, whenever the window > is raised. (This would be to prevent breaking any clients that only expect > expose events when the window is raised.) This would also cope properly > with a situation in which memory for the backing store pixmap becomes available > sometime after a client has started. The backing store could be assumed to > have been initialised if written to prior to being raised. > Correct behaviour is defined by the protocol spec (page 474 of the Digital Press 2nd edition): "This event [Expose] is reported to clients selecting Exposure on the window. It is generated when no valid contents are available for regions of the window, and either: - the regions are visible, - the regions are viewable and the server is (perhaps newly) maintaining backing store on the window, - or the window is not viewable but the server is (perhaps newly) honoring [the] window's backing-store attribute of Always or WhenMapped. What this means is that you should select for Exposure in the CreateWindow if the backing-store attribute is Always, because the server will generate the Expose immediately and if you aren't listening it will be lost, and never de-select Exposure on a window that has backing-store Always, because the server may decide to start maintaining it at any time. This is good practice if the window has backing-store WhenMapped, because otherwise there are potential race conditions between the map/unmap and the select/deselect of Exposure that you are unlikely to get right. David.
cjmchale@cs.tcd.ie (Ciaran McHale) (03/06/91)
In <952@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article <9103032356.AA00215@devnull.Eng.Sun.COM> >dshr@eng.sun.COM (David Rosenthal) writes: > >>This is a very important point to understand. If we had been prepared to >>*require* the server to maintain backing store for windows and to make >>a number of other similar decisions during the design of X, we would have >>ended up with a completely different design which would have >>been faster and simpler but which would have consumed much more resource. >>It would, for example, have been improbable that an X-terminal or a >>PC X-server would have been a viable product had we taken this route. > >I couldn't agree with you less on this last statement. Case in point: >The Amiga guarentees backing store with it's SMART_REFRESH windows. >The programmer is able to choose whether they can handle expose >events or not. SIMPLE_REFRESH windows always generate expose events >whenever it is uncovered. SMART_REFRESH windows do not. >If the Amiga was able to do this in a 16k layer library and a 64k >graphics library (nearly all written in C) then it could be done >in the X Window system as well. The problem isn't in writing code to support the unconditionaly maintainence of backing store; the problem is that you can't be sure the X server has enough main memory to do so. I don't know much about the Amiga but in the X window system a window can be quite large: 2^16 wide by 2^16 high. (that's 2^9 Megabytes for a mono window if my maths is correct.) I don't think it is reasonable to expect an X server to maintain backing store for windows that big. I would imagine that the Amiga either (i) puts an upper limit on how big a SMART_REFRESH window can be, or (ii) runs out of memory for large SMART_RESFRESH windows. X *could* have done this. But it didn't because the designers thought that it might be a bit limiting. Ciaran. -- Ciaran McHale "Verbosity says it all" ____ Department of Computer Science, Trinity College, Dublin 2, Ireland. \ / Telephone: +353-1-772941 ext 1538 FAX: +353-1-772204 \/ Telex: 93782 TCD EI email: cjmchale@cs.tcd.ie
pds@quintus.UUCP (Luis Jenkins) (03/06/91)
In article <9103041710.AA12610@asl.dl.nec.com> ekberg@asl.dl.nec.COM (Tom Ekberg) writes: > 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. If save-unders is True, the server can > support the save-under mode in CreateWindow and ChangeWindowAttributes, > although again it may be storage limited. This doesn't make a lot of sense. If I know I can't count on the server to provide backing store, then I'll have to keep a pixmap the size of my window to back it myself (asuming that this is the sort of application where it just doesn't make sense to redraw the window from first principles). If I allocate that pixmap, then that much server memory is occupied, so if the server would have been unable to maintain backing store for me, it certainly will be unable to give me my pixmap (or else it won't allow some other process to have the resources it needs). If it guaranteed me backing store, it would only have to allocate resources for the part of my window that is occluded. Besides, if I have to back up my window myself, I have to do 2 drawing operations for every one I would do if I had backing store. -- -Peter Schachte pds@quintus.com ...!{uunet,sun}!quintus!pds
barmar@think.com (Barry Margolin) (03/06/91)
In article <952@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >If the application is required to maintain the backing pixmap, guess what? >The same resources get chewed too. But they aren't really the *same* resources. Clients (certainly complex ones that produce such complicated output that it can't be regenerated easily) generally run on powerful computers with lots of physical memory and virtual memory with lots of swap space. Servers are frequently small-memory X terminals, or PCs without virtual memory. A megabyte on the server is a much bigger deal than on the client machine. >So now let's say the server does do backing store but the client can depend on >it? So they now do there own backing store, but the user has requested that >all windows have backing store and we see that the server now wastes backing >store bits on a window that is doing its own backing store. So when that window >goes behind all others we see the server eating twice as much memory for that >window. I don't understand the above paragraph. Was the "can" in the first sentence supposed to be "can't"? In either case, why is the *server* eating *twice* as much memory? > >IMHO, there is nothing wrong with a decision by a company to specify >that the servers that are used to display their application must have a >working backing store implementation as well as enough resources(memory) to >insure that the bits do not get lost during standard operation of the program. >These are prerequisites for running this application. How much is "enough resources"? The server doesn't know how many windows the application plans on opening. It doesn't know how many applications will be trying to use it. It can only maintain backing store for a finite number of windows simultaneously, and not too many if it only has physical memory to use. >The Amiga guarentees backing store with it's SMART_REFRESH windows. >The programmer is able to choose whether they can handle expose >events or not. SIMPLE_REFRESH windows always generate expose events >whenever it is uncovered. SMART_REFRESH windows do not. >If the Amiga was able to do this in a 16k layer library and a 64k >graphics library (nearly all written in C) then it could be done >in the X Window system as well. It has nothing to do with the size of the library. The X server can faithfully maintain backing store for as long as it has memory. Since backing store is considered just an optimization, the X designers specified that it has lower priority than other things; if the server needs to throw away some backing store in order to allow another window to be opened or a font to be loaded, it may, since fonts and windows are more important than backing store. How many SMART_REFRESH windows can you have at one time on an average sized Amiga? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
melby@pappa.yk.fujitsu.co.jp (John Melby) (03/06/91)
>If the application is required to maintain the backing pixmap, guess what? >The same resources get chewed too. So what should the application now >do if those resources are chewed up and it has been a good citizen managing >it's own backing store? This is true if pixmaps are being used to back the display. However, if images are used and the server and client are on different machines, this does not necessarily hold. (Of course, if they are linked over a 9600 bps line and the user issues an XFlushDisplay(), that's an entirely different matter....) ----- John B. Melby Fujitsu Limited, Machida, Japan melby%yk.fujitsu.co.jp@uunet
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/06/91)
> [C]ould someone throw some light on why setting backing store to > "always" as opposed to "not useful" or "when mapped" breaks many > clients written in the standard fashion. Well, if you go in and bash one small item in a program without understanding how it interacts with the rest of the program, you deserve to lose. > What seems to happen is that since the backing pixmap is created on > window creation, then raising the window doesn't generate an expose, > so the client never draws anything to the window. The client should have drawn when the first Expose event was generated, back when the backing-store was created at the same time the window was. If the client didn't select for ExposureMask at create time, that's the reason: setting backing-store to Always is incompatible with selecting for ExposureMask only after window creation. > In other words, the server seems to go to extremes in avoiding > sending expose events to the client, to the point where it is not > initialising the backing pixmap ! This seems like a bug in the > server backing store code. If you *did* include ExposureMask in the event-mask when the window was created and *still* don't see the Expose event, yes, your server is buggy. But this seems doubtful. > (This would be to prevent breaking any clients that only expect > expose events when the window is raised.) Such clients shouldn't exist. Even if the server doesn't do backing-store at all, such an expectation may (and therefore eventually *will*) break. Your `only' is ambiguously placed, but I can't find a place to attach it that doesn't make the expectation dangerous: Expose events can be sent at any time due to other windows disappearing, and may not be sent on window raise if the window was unobscured to begin with. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/06/91)
> So they [clients] now do there [sic] own backing store, but the user > has requested that all windows have backing store and we see that the > server now wastes backing store bits on a window that is doing its > own backing store. So when that window goes behind all others we see > the server eating twice as much memory for that window. Yup, that's the price the user pays for trying to second-guess programs about the usefulness of backing-store for their windows. > IMHO, there is nothing wrong with a decision by a company to specify > that the servers that are used to display their application must have > a working backing store implementation as well as enough resources > (memory) to insure that the bits do not get lost during standard > operation of the program. These are prerequisites for running this > application. I would not say *nothing* wrong. It is an entirely self-consistent point of view, I suppose. However, when the program is sold as an X program, there is the implication that it runs on an X server. And X servers are permitted to drop backing-store at any time, for any reason. If the product requires an X-plus-guaranteed-backing-store server, it should be up-front about it. While I have not seen the marketing propaganda for the product in question, I have no doubt it does not mention anything of the sort. (Would whoever posted the original message care to check and tell me?) >> If we had been prepared to *require* the server to maintain backing >> store for windows and [...], [we'd have a design] [...] which would >> have consumed much more resource[s]. It would, for example, have >> been improbable that an X-terminal or a PC X-server would have been >> a viable product had we taken this route. > I couldn't agree with you less on this last statement. Case in > point: The Amiga guarentees backing store with it's SMART_REFRESH > windows. The programmer is able to choose whether they can handle > expose events or not. SIMPLE_REFRESH windows always generate expose > events whenever it is uncovered. SMART_REFRESH windows do not. If > the Amiga was able to do this in a 16k layer library and a 64k > graphics library (nearly all written in C) then it could be done in > the X Window system as well. And, of course, the Amiga windowing system and X are identical in all other respects. Riiiight. (I actually think dshr wasn't talking about code space size as much as run-time memory usage.) Have you looked at how complicated it would be to add a Guaranteed backing-store "hint" value? I haven't. I doubt you have; if you have, please correct me and I'll shut up. Until then, I think we should both take the word of someone who can be presumed to know what he[%]'s talking about.... [%] "David" seems to imply "he" rather strongly :-) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/06/91)
>> A problem encountered with both products is that if a graphics >> window is overlaid ( e.g. by a menu ), the overlaid portion is not >> restored. [...backing-store...] > Just for your information, what you just described above is not > backing store but save unders. Backing store works when anything BUT > a menu which obscures another window is moved so the current window > is exposed. Yes and no. If the saving is controlled by a bit on the menu, it's a save-under; if by a bit on the window underneath, it's backing-store. Some (older) implementations actually handle save-unders by turning on backing-store on obscured windows; this can be catastrophic if the window underneath is huge and is being clipped by its parent. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
msm@src.dec.com (Mark S. Manasse) (03/07/91)
In one system I know of (namely, the only one that currently has patent rights to use backing store), backing store guarantees are absolute: you won't lose any of your old bits. In return, attempts to configure windows and create windows fail when the window system runs out of memory in which to maintain backing store. One can argue about whether this simplifies or complicates clients; I know that I found it confusing as a user that I sometimes couldn't move a window from one place on the screen to another. Mark
dbrooks@osf.org (David Brooks) (03/07/91)
In article <1991Mar6.094926.8556@src.dec.com>, msm@src.dec.com (Mark S. Manasse) writes: |> In one system I know of (namely, the only one that currently has patent |> rights to use backing store), backing store guarantees are absolute: you |> won't lose any of your old bits. |> |> In return, attempts to configure windows and create windows fail when the |> window system runs out of memory in which to maintain backing store. Is it possible to imagine a server that has access to a sufficiently large area of disk, so that really LRU windows get dumped there? Didn't we used to call disk "backing store"? Of course, this runs contrary to the trend, but it's surely one way of making a server with a reasonably sized backing-store available in a highly-specified environment. -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks "It's not easy, but it is simple."
sarima@tdatirv.UUCP (Stanley Friesen) (03/07/91)
In article <952@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >I couldn't agree with you less on this last statement. Case in point: >The Amiga guarentees backing store with it's SMART_REFRESH windows. >The programmer is able to choose whether they can handle expose >events or not. SIMPLE_REFRESH windows always generate expose events >whenever it is uncovered. SMART_REFRESH windows do not. Oh, aye, so it does, but read the fine print. All of the memory has to be allocated when the window is created, and I believe most of it must be in memory accessible to the graphics chip (about 512K on older systems). You can only create a very few such windows before running completely out of memory. So, yes, it is possible, at tremendous cost (only a few windows allowed, unless they are very small). Now, if you will only have one or two apps running, and they only need one or two SMART_REFRESH windows each, then this is fine. BUT, for a more general system, with reasonable limits, this is not good enough. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) (03/07/91)
>> In one system I know of [...], backing store guarantees are >> absolute: you won't lose any of your old bits. >> In return, attempts to configure windows and create windows fail >> when the window system runs out of memory in which to maintain >> backing store. > Is it possible to imagine a server that has access to a sufficiently > large area of disk, so that really LRU windows get dumped there? > Didn't we used to call disk "backing store"? This sounds to me like a conventional X server running on a workstation that supports virtual memory backed by a large chunk of disk space. Did you mean something different, and if so, what? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
dbrooks@osf.org (David Brooks) (03/08/91)
mouse@lightning.mcrcim.mcgill.EDU (der Mouse) writes: |> > Is it possible to imagine a server that has access to a sufficiently |> > large area of disk, so that really LRU windows get dumped there? |> |> This sounds to me like a conventional X server running on a workstation |> that supports virtual memory backed by a large chunk of disk space. |> Did you mean something different, and if so, what? Considering the context included this: |> >> In return, attempts to configure windows and create windows fail |> >> when the window system runs out of memory in which to maintain |> >> backing store. I'm really thinking of a server running on a machine that has a limited virtual address space, but access to a large amount of ordinary file space (like a PC on a network). Then, using conventional file storage, one could take the architectural decision to go the next step. I'm still assuming we're talking about an application that absolutely requires backing store, and runs in the proverbial environment which is highly controlled. -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks "It's not easy, but it is simple."
dale@boing.UUCP (Dale Luck) (03/09/91)
In article <163@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: >In article <952@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >>The Amiga guarentees backing store with it's SMART_REFRESH windows. > >Oh, aye, so it does, but read the fine print. All of the memory has >to be allocated when the window is created You better clean your glasses, this is completely untrue. The Amiga only allocates backingstore bitmaps when portions of smart refresh windows are covered up. They are returned to the system when exposed. Maybe you are thinking about superbitmaps which are actually large preallocated pixmaps in which all the bits are preserved no matter how big the on screen window is. Sizing this one bigger automatically brings bits from the larger pixmap onto the screen. >--------------- >uunet!tdatirv!sarima (Stanley Friesen) -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
ckp@grebyn.com (Checkpoint Technologies) (03/09/91)
In article <952@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >The Amiga guarentees backing store with it's SMART_REFRESH windows. ..and then, sometime later it crashes the system with an OUT OF MEMORY alert when there is no longer enough chip RAM. Somehow I find I prefer the X backing store policy that backing is no longer done when the server cannot do it, however your application keeps running. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
dale@boing.UUCP (Dale Luck) (03/11/91)
In article <1991Mar9.154127.27485@grebyn.com> ckp@grebyn.com (Checkpoint Technologies) writes: >In article <952@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >>The Amiga guarentees backing store with it's SMART_REFRESH windows. > >..and then, sometime later it crashes the system with an OUT OF MEMORY >alert when there is no longer enough chip RAM. The person responsible for this piece of misinformation needs to do a little more research. Maybe the message appearing as an anomonous post indicates this person does not want to admit to making this comment. The Amiga does not alert when it runs out of graphics memory that may be required to support guarenteed backing store. The function that may have required more backing store to be allocated fails and the system keeps running along. >Somehow I find I prefer >the X backing store policy that backing is no longer done when the >server cannot do it, however your application keeps running. We had looked at a new type of window type called JANUS, which implemented the X Window type of window refresh policy. It was not done due to lack of time. >-- >First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / > \\ / / >Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o >Now for the witty part: I'm pink, therefore, I'm spam! \/ -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
sarima@tdatirv.UUCP (Stanley Friesen) (03/12/91)
In article <953@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article <163@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: >>Oh, aye, so it does, but read the fine print. All of the memory has >>to be allocated when the window is created > >You better clean your glasses, this is completely untrue. The Amiga only >allocates backingstore bitmaps when portions of smart refresh windows >are covered up. They are returned to the system when exposed. ... Oops, sorry about that. It has been some time since I read the ROM Kernel Manuals. Actually, I was remembering the general fact that the manuals find it necessary to *constantly* remind you about memory allocation, and that most graphics must be in the limited sub-set of memory called chip memory. [For you non-Amiga types, chip memory is the memory addressable by the independent graphics chip that actually draws the Amiga graphics]. However, as someone else pointed out, the fine print on Smart_Refresh is even *worse*, it simply generates a run-time error when you run out of chip memory!! Bleah! All of this is why no one in thier right mind runs an Amiga with less than 2 MB of memory (preferable more). This is *lots* of memory for a cheap graphics terminal, so this solution is unusable in an X environment. In general I like the Amiga, but I think its memory management *sucks* *eggs*. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)