PJS@GROUCH.JPL.NASA.GOV (Peter Scott) (04/23/89)
I just started learning X-Windows, and had assumed that if a window were obscured or closed, that X would save its contents and automatically restore them when the window or part of window became displayable. But from my reading it appears that redisplay is the responsibility of the programmer. Let me get this straight. If, for instance, I am writing a painting program, then either I have to keep a journal of all the user's paint commands, and replay them whenever I am redisplayed, or I have to save the bitmap for the window each time the window is modified, and restore from that if I am obscured? Suppose I have backing store supported and enabled. Does X automatically restore the contents of the window in this case? Peter Scott (pjs@grouch.jpl.nasa.gov)
mcintyrd@cs.rpi.edu (David McIntyre) (04/24/89)
Peter Scott writes: >I just started learning X-Windows, and had assumed that if a window were >obscured or closed, that X would save its contents and automatically >restore them when the window or part of window became displayable. But >from my reading it appears that redisplay is the responsibility of the >programmer. Let me get this straight. If, for instance, I am writing >a painting program, then either I have to keep a journal of all the user's >paint commands, and replay them whenever I am redisplayed, or I have to >save the bitmap for the window each time the window is modified, and >restore from that if I am obscured? Yes, that is correct. Redisplaying damaged window contents is the problem of the client program. >Suppose I have backing store supported and enabled. Does X automatically >restore the contents of the window in this case? Yes, that takes care of the problem. Backing store keeps the current contents of the window, and will re-expose damaged portions. Dave "mr question" McIntyre | "....say you're thinking about a plate mcintyre@turing.cs.rpi.edu | of shrimp.....and someone says to office : 518-276-8633 | you `plate,' or `shrimp'......" home : 518-271-6664 |
mlandau@bbn.com (Matt Landau) (04/24/89)
In comp.windows.x (<1438@rpi.edu>), mcintyrd@cs.rpi.edu (David McIntyre) writes: >Yes, that takes care of the problem. Backing store keeps the current >contents of the window, and will re-expose damaged portions. Please remember that asking an X server for backing store on a window is merely a *hint* that you'd like to minimize redraw requests for that window. An X server is under no obligation to provide backing store, and is free to ignore requests for backing store on windows. Moreover, a server that does choose to provide backing store may stop providing it at any time during a session if it decides it's running out of resources. A correctly written X client that wishes to be portable to different servers MUST assume that it may be called on to regenerate any or all of its display at any time, subject to the rules laid out in the protocol spec for X11. -- Matt Landau Oblivion gallops closer, mlandau@bbn.com favoring the spur, sparing the rein.
bzs@bu-cs.BU.EDU (Barry Shein) (04/24/89)
Also, the original poster was being too object-oriented with his example of a draw program. You can also draw into a memory pixmap and blow that to the window in one shot when needed (or various variations on that theme, send only the region needed etc.) -- -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (04/24/89)
> But from my reading it appears that redisplay is the responsibility of > the programmer. Yep. > Let me get this straight. If, for instance, I am writing > a painting program, then either I have to keep a journal of all the user's > paint commands, and replay them whenever I am redisplayed, or I have to > save the bitmap for the window each time the window is modified, and > restore from that if I am obscured? Those are two ways of doing it, personally I would like to see you keep a list of those things that make visable changes to the window, and then redraw this list. This will be the most memory efficient method of doing it. Performace is another matter entirely. > Suppose I have backing store supported > and enabled. Does X automatically restore the contents of the window in > this case? Maybe. You should still be able to refresh the contents of your window since you can never count on backing store being avaliable. That is why it is a hint the server can choose to ignore your request for backing store at any time. Remeber that backing store is a convience, DON'T RELY ON BACKING STORE TO BE AVALIABLE. Chris D. Peterson MIT X Consortium
dshr@SUN.COM (David Rosenthal) (04/25/89)
Dave "mr question" McIntyre writes: > >Suppose I have backing store supported and enabled. Does X automatically > >restore the contents of the window in this case? > > Yes, that takes care of the problem. Backing store keeps the current > contents of the window, and will re-expose damaged portions. > This is seriously misleading. Backing-store is a HINT, not a command. The server may stop maintaining backing-store at any time, for any reason. The use of backing store makes no difference to program structure. The client still has to be capable of restoring the contents of a window. All the backing store does is to reduce the frequency with which the code that restores the window will be executed. There is no escape. It is a fundamental requirement of X that the client respond to Expose events by re-painting the exposed area. If you don't like this requirement, go find yourself some other window system. This requirement is one of the reasons why X is simple and portable to a wide range of displays, so the other window system you find is not likely to be as widespread or successful as X. David.
peter@ficc.uu.net (Peter da Silva) (04/26/89)
In article <8904251538.AA00185@devnull.sun.com>, dshr@SUN.COM (David Rosenthal) writes: > There is no escape. It is a fundamental requirement of X that the client > respond to Expose events by re-painting the exposed area. If you don't > like this requirement, go find yourself some other window system. This > requirement is one of the reasons why X is simple and portable to a wide > range of displays, so the other window system you find is not likely > to be as widespread or successful as X. Now I may be dim, but I don't see how the lack of a guaranteed backing store leads to the increased portability of X. One might as well say that the ability to operate without a mouse leads to the increased portability of Microsoft Windows (yes, Windows works quite well without a mouse). If the display server doesn't have a backing store it can be emulated in the client library, though I find it hard to imagine a hardware system that can support X that doesn't have memory to burn. I've worked with a windowing system that gives you the option of using or not using a reliable backing store. The performance enhancement having such a resource is considerable, as is the degree to which it simplifies the job of programming. I just started working on an X machine, and all the disadvantages of working without a backing store are painfully evident in this display. Every expose event is followed by agonizing widget-by-widget repaints. Think of a backing-store as curses for your server. Or do you really prefer working directly with termlib? Backing up: > If you don't like this requirement, go find yourself some other window > system. I'd love to. X is the Fortran of windowing. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
rws@EXPO.LCS.MIT.EDU (04/27/89)
I find it hard to imagine a hardware system that can support X that doesn't
have memory to burn.
It doesn't take ANY imagination to find such hardware. Anyone walking the
floor at the recent Uniforum saw LOTS of such hardware.smithey@esosun.UUCP (Brian Smithey) (04/27/89)
In article <3985@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Now I may be dim, but I don't see how the lack of a guaranteed backing store >leads to the increased portability of X. One might as well say that the ability >to operate without a mouse leads to the increased portability of Microsoft >Windows (yes, Windows works quite well without a mouse). If the display server >doesn't have a backing store it can be emulated in the client library, though If the client can get enough memory ... >I find it hard to imagine a hardware system that can support X that doesn't >have memory to burn. How about the servers for non-virtual memory micros, such as the Amiga and Mac? >Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Brian -- Brian Smithey / SAIC, Geophysics Division / San Diego CA uucp: uunet!seismo!esosun!smithey Internet: smithey%esosun.css.gov@seismo.css.gov
peter@ficc.uu.net (Peter da Silva) (04/28/89)
In article <466@esosun.UUCP>, smithey@esosun.UUCP (Brian Smithey) writes: > In article <3985@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >Now I may be dim, but I don't see how the lack of a guaranteed backing store > >leads to the increased portability of X. > >I find it hard to imagine a hardware system that can support X that doesn't > >have memory to burn. > How about the servers for non-virtual memory micros, such as the Amiga > and Mac? That's an interesting comparison, since the Amiga windowing system does guarantee a backing-store for all windows. If Intuition can do it, why not X? Particularly since with Intuition the Amiga is both the client and the server... An aside: Speaking of clients and servers, the NeWS people don't seem to use the same polarity of terminology. Am I misunderstanding or is there a conflict here? -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
rws@EXPO.LCS.MIT.EDU (04/28/89)
That's an interesting comparison, since the Amiga windowing system does
guarantee a backing-store for all windows. If Intuition can do it, why
not X?
How does Intuition do it? Does it pop up a message: "Please insert floppy
number 137, I need to save/retrieve some backing-store bits" ? They must be
trading off something somewhere. For example, do they guarantee backing-store
regardless of how big you later make the window? Does that mean they
preallocate max-sized memory chunks for every window created? Is there a
small limit to the number of windows that can be created? Or does the
"guarantee" mean the system will crash unexpectedly at some point?
Speaking of clients and servers, the NeWS people don't seem to use the same
polarity of terminology. Am I misunderstanding or is there a conflict here?
The X terminology is from the point of view of the network connections.
The thing that listens for and accepts connections from others is the server,
the thing that attempt to establish a connection is the client. This is
quite consistent with the terminology in Sun's "NeWS Technical Overview", so
I don't know which "NeWS people" you are talking about (maybe ones who've
lost their backing store :-).meo@stiatl.UUCP (Miles O'Neal) (04/28/89)
In article <4009@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: | In article <466@esosun.UUCP>, smithey@esosun.UUCP (Brian Smithey) writes: | > In article <3985@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: | > >Now I may be dim, but I don't see how the lack of a guaranteed backing store | > >leads to the increased portability of X. | | > >I find it hard to imagine a hardware system that can support X that doesn't | > >have memory to burn. | | > How about the servers for non-virtual memory micros, such as the Amiga | > and Mac? | | That's an interesting comparison, since the Amiga windowing system does | guarantee a backing-store for all windows. If Intuition can do it, why | not X? Particularly since with Intuition the Amiga is both the client and | the server... Excuse this lo-tech intrusion, but what about all the 386 systems, running both DOS and Unix (or even - gak - the O word)? And X Display Stations, such as the XDS terminals from Visual? Assuming you could put "memory to burn" into the XDS and related terminals, the price would impinge into the workstation range. Somewhere down the road, it may be reasonable to expect everything that might run X to have display backing-store, but not now. Sure, I realize what this means, as I write widgets & applications. But that's reality... -Miles O'Neal (gatech!stiatl!meo)
dale@boing.UUCP (Dale Luck) (04/30/89)
In article <8904281155.AA02450@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU writes: > > That's an interesting comparison, since the Amiga windowing system does > guarantee a backing-store for all windows. If Intuition can do it, why > not X? > >How does Intuition do it? Does it pop up a message: "Please insert floppy >number 137, I need to save/retrieve some backing-store bits" ? They must be >trading off something somewhere. For example, do they guarantee backing-store >regardless of how big you later make the window? Does that mean they >preallocate max-sized memory chunks for every window created? The Amiga windowing system does guarentee that all bits are preserved. It is able to do this by not allowing operations that would irreversably lose those bits. If a window is placed such that it is behind another window and the bits need to be saved off screen it allocates them on the fly. If they cannot be allocated it backs out of the operation and returns an error that the window could not be moved. The important thing here is that it does not lose the contents of the window. The Amiga windowing system maintains several kinds of windows. Windows that do not need backing store (Simple), whose bits are never preserved when something covers them up on the shared bitmap; Windows that do need backing store (Smart), in which extra backing store is only allocated in case of occlusion; and also superbitmap windows, in which there is a complete bitmap/pixmap allocated for the window. Smart refresh windows lose there bits if they are sized down and sized back up, generating a refresh event. Simple windows always generate refresh events in the case of uncovering a portion on the display. Superbitmaps never generate refresh events. Is there a >small limit to the number of windows that can be created? Nope, depends on how much memory you have. > Or does the guarantee" mean the system will crash unexpectedly at some point? Give me a break, rws. Have you used the Amiga and seen it crash by just playing with the placement and geometry of the windows? The technology used by the layer library in the Amiga window system is setjmp/longjmp based. When operations occur that may require more memory to be consumed, they are done in a very careful order. For instance we allocate the new set of structures and associated bitmaps before freeing the original ones, etc. This allows the Amiga to back out of a partially completed operation and restore the state of the machine before the operation took place if a memory allocation fails. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
peter@ficc.uu.net (Peter da Silva) (04/30/89)
In article <8904281155.AA02450@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU writes: > That's an interesting comparison, since the Amiga windowing system does > guarantee a backing-store for all windows. If Intuition can do it, why > not X? > How does Intuition do it? [silly suggestions] What it means is that if you open windows forever eventually OpenWindow will return an error code instead of a (struct Window *), or a resize event will fail, or you'll find that you can't move a window. Generally I find that LoadSeg has failed first. If rendering is time-consuming it's nice to know that some dodo won't zap your Mandelbrot in mid-compute. [confusion about NeWS] I was confused by a discussion about applications running in the Server. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
peter@ficc.uu.net (Peter da Silva) (04/30/89)
In article <4434@stiatl.UUCP>, meo@stiatl.UUCP (Miles O'Neal) writes: > Excuse this lo-tech intrusion, but what about all the 386 systems, running both > DOS and Unix (or even - gak - the O word)? And X Display Stations, such as the > XDS terminals from Visual? The smallest X terminal I know of is the Acer Xebra. From its specs it sounds like a disguised IBM-PC with 640K and a Hercules card. Given the limitations of the hardware, 640K sounds like scads of memory. The Amiga runs in 512K with both the application and the windows sharing that memory. And given that 386 UNIX machines with enough RAM to run X typically burn a Meg for disk buffers, complaining about a bit of backing store doesn't really make a whole lot of sense. [yes, I know UNIX is too big, X is too big, etc... but you might as well be hung for a sheep as for a lamb.] -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
rws@EXPO.LCS.MIT.EDU (05/01/89)
If they
cannot be allocated it backs out of the operation and returns an error that
the window could not be moved. The important thing here is that it does not
lose the contents of the window.
This is a particular policy decision, one that may be fine for some
environments, but probably not all. For example, this may mean that a
client at some point cannot get a dialog box popped up to ask the user some
vital question, or to warn the user of some vital event (e.g. system shutdown),
because the system believes backing-store bits are more important than a new
window. Of course in any memory-limited system this kind of thing will happen
eventually. But in a system with very limited memory, like an X terminal, it
isn't obvious to me that this policy is universally the right one.
Give me a break, rws. Have you used the Amiga and seen it crash by just
playing with the placement and geometry of the windows?
No, I've never used an Amiga, period, which is why I asked the question.
Sorry if I've offended you with my ignorance.peter@ficc.uu.net (Peter da Silva) (05/02/89)
In article <8905011149.AA00201@expire.lcs.mit.edu>, rws@EXPO.LCS.MIT.EDU writes: > This is a particular policy decision, This terminology is a mite confusing... what do you mean by a policy decision. The decision to force client programs to support disclose events is as much a policy decision as the decision to force the server to retain obscured bitmaps. > one that may be fine for some > environments, but probably not all. For example, this may mean that a > client at some point cannot get a dialog box popped up to ask the user some > vital question, or to warn the user of some vital event... The Amiga deals with this problem with what are called 'alerts'. An alert is implemented with a small dedicated bitmap, just big enough to allow the system to open a standard sized 'window' and ask a yes/no question. The user responds by clicking the left or right mouse button. Programs call a routine called "DisplayAlert" to get an alert. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (05/02/89)
In article <4037@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <4434@stiatl.UUCP>, meo@stiatl.UUCP (Miles O'Neal) writes: >> Excuse this lo-tech intrusion, but what about all the 386 systems, running both >> DOS and Unix (or even - gak - the O word)? And X Display Stations, such as the >> XDS terminals from Visual? > >The smallest X terminal I know of is the Acer Xebra. From its specs it sounds >like a disguised IBM-PC with 640K and a Hercules card. Given the limitations >of the hardware, 640K sounds like scads of memory. The Amiga runs in 512K >with both the application and the windows sharing that memory. How many bits do you need to save for each window? A workstation's windows I presume would take up significantly more memory: A sun is 1152x900 (??) vs. 640 x 200? In BW I suspect that most Suns would have plenty of memory for backing store, but with color, things might get tight. Can the Amiga run the whole server and clients in 512K of memory, when that 512 also includes the frame buffer??? It MUST have shared libraries then, which many Eunixes seem to lack. I think the Amiga's choice to make backing store available for every window and then return errors when it's out of memory seems like a mistake: I would rather have things work but run slowly than crash quickly. By extension, why have virtual memory at all? Just return an error code when it runs out. Another question: does backing-store only apply to the visble parts of the window, or could you conceivably make a gigantic window that you only see a little bit at a time. If backing-store were required for the whole window, this would be bad news. >-- >Peter da Silva, Xenix Support, Ferranti International Controls Corporation. > >Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. >Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. Matt Kennel mbkennel@phoenix.princeton.edu
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (05/02/89)
In article <723@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > The technology used by the layer library in the Amiga window system is >setjmp/longjmp based. When operations occur that may require more memory to be >consumed, they are done in a very careful order. For instance we allocate the >new set of structures and associated bitmaps before freeing the original ones, etc. >This allows the Amiga to back out of a partially completed operation and restore >the state of the machine before the operation took place if a memory allocation >fails. > Correct me if I'm wrong, but I have heard that the Amiga only allocates nonrelocatable blocks of memory. Without the use of hardware memory mapping (does it do that?) I would guess that frequent changes of the windows combined with many allocates/deallocates would result in memory fragmentation that would cause memory requests to fail (needed for backing store etc.) even when there is enough actual memory left. (But not contiguously) It's really hard to believe that 512k would hold up long for server, clients, and display in this situtation. >-- >Dale Luck GfxBase/Boing, Inc. >{uunet!cbmvax|pyramid}!amiga!boing!dale Matt Kennel mbkennel@phoenix.princeton.edu
rws@EXPO.LCS.MIT.EDU (05/02/89)
The decision to force client programs to support disclose events is as much
a policy decision as the decision to force the server to retain obscured
bitmaps.
Agreed. I wasn't really trying to imply otherwise. X has chosen one, the
Amiga has chosen another. I don't think there are cut-and-dried arguments
on either side.
The Amiga deals with this problem with what are called 'alerts'. An alert
is implemented with a small dedicated bitmap, just big enough to allow the
system to open a standard sized 'window' and ask a yes/no question.
This is kind of imposing on someone's GUI style guide, isn't it ...bpendlet@esunix.UUCP (Bob Pendleton) (05/03/89)
From article <4037@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): >And given that 386 UNIX machines with enough RAM to run X typically burn a Meg >for disk buffers, complaining about a bit of backing store doesn't really make >a whole lot of sense. A bit of backing store? Lets see, my default xterm window size is 80x60 using an 8x13 font so that is 499200 pixels. On a machine with 32 bits/pixel (yes, such machines exist and run X) thats 1,996,800 bytes or 1.95 megabytes. Please don't write applications that depend on backing store. Unless it gets written into the standard, you aren't always going to have it. Bob P. -- - Bob Pendleton, speaking only for myself. - UUCP Address: decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet - - Reality is stranger than most can imagine.
dale@boing.UUCP (Dale Luck) (05/04/89)
In article <8078@phoenix.Princeton.EDU> mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) writes: >In article <4037@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >Can the Amiga run the whole server and clients in 512K of memory, when >that 512 also includes the frame buffer??? It MUST have shared libraries >then, which many Eunixes seem to lack. Yes, the amiga was one of the pioneers in dynamically loaded sharable reentrant libraries. > >I think the Amiga's choice to make backing store available for every window >and then return errors when it's out of memory seems like a mistake: I would >rather have things work but run slowly than crash quickly. By extension, >why have virtual memory at all? Just return an error code when it runs out. Where does crash come in? In most cases when you are low on memory it is the user that is playing around with the windows. If they try to move or resize a window and see that it does not move, they usually realize they are running low on memory. But actually this whole discussion about saving bits instead of dropping the bits off the table as a matter of policy is not the issue at all. The issue is what do you do when you run out of a resource to do an operation. Memory is just one of those resources. There are plenty of other gotchas in X when it runs out malloc memory. So those requests seem already bound for a possible failure return. > >Another question: does backing-store only apply to the visble parts of the >window, or could you conceivably make a gigantic window that you only >see a little bit at a time. If backing-store were required for the whole >window, this would be bad news. Usually backing store is only needed for the obscured parts of the window. If you don't need backing store then don't ask for it. User's of machines that have real memory limitations get quickly acustomed to the limitations and how to get around them, as long as it does not crash and gives them a chance. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
dale@boing.UUCP (Dale Luck) (05/04/89)
In article <8079@phoenix.Princeton.EDU> mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) writes: >In article <723@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > >Correct me if I'm wrong, but I have heard that the Amiga only allocates >nonrelocatable blocks of memory. Without the use of hardware memory >mapping (does it do that?) You are correct here. That there is no hardware mapping. Being that there is no hardware mapping though, we take advantage of the fact that any hunk of memory that needs to be allocated to a process is only as big as it needs to be. This avoids internal fragmentation which is a problem in memory mapped systems. If a process needs to allocate 40 bytes for a Pixmap structure we don't need to allocate a 1k page for 40 bytes. I would guess that frequent changes of the >windows combined with many allocates/deallocates would result in memory >fragmentation that would cause memory requests to fail (needed for >backing store etc.) even when there is enough actual memory left. (But not >contiguously) This is true on memory mapped systems as well. Except that all allocations from the global memory pool are the size of a page. Much of this depends on how close to the edge you are living. If there is normally 256k free then the deallocations are normally balanced with the allocations. The basic structures don't change that describe the topology, usually it is just different windows that get them and other windows that loose them. The Amiga also has two types of memory. Graphics memory (accessable by the blitter and processor) and expansion memory(accessable only by the processor). So only the actual bitmaps are placed in 'graphics memory' whereas the structures the define them and control the operation of the processor are stashed in another memory pool. It's really hard to believe that 512k would hold up long >for server, clients, and display in this situtation. The server exists in ROM. The display takes up about 32k-64k. Clients are about 2k-100k. We are talking Amigados now, not X-windows. The amiga has shared libraries like floating point, graphics, toolkit wm(Intuition), and much of the support functions are found in shared libraries. I guess you can start believing now, software technology moves on. Maybe you should check an Amiga out sometime to see what it actually offers. > >Matt Kennel >mbkennel@phoenix.princeton.edu -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
mmengel@cuuxb.ATT.COM (Marc W. Mengel) (05/05/89)
In article <8078@phoenix.Princeton.EDU> mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) writes: >>of the hardware, 640K sounds like scads of memory. The Amiga runs in 512K >>with both the application and the windows sharing that memory. >Can the Amiga run the whole server and clients in 512K of memory, when >that 512 also includes the frame buffer??? It MUST have shared libraries >then, which many Eunixes seem to lack. > >I think the Amiga's choice to make backing store available for every window >and then return errors when it's out of memory seems like a mistake: I would >rather have things work but run slowly than crash quickly. By extension, >why have virtual memory at all? Just return an error code when it runs out. The Amiga does it this way because that is how its native windowing system works; which in turn is based on its hardware architecture. (If I recall correctly) the Amiga low level graphics routines take a pixmap-ish structure that the *application* program owns and has allocated, and hardware bitblits it onto the frame buffer for the screen. These same low-level libraries also maintain things like animation objects cruising accross the screen, etc. and may in fact just make the video chip look at your bitmap instead of the screen bitmap temporarily to display it, rather than copying it onto the screen at all. By making the X server use this paradigm as well (which forces it to keep backing store for everything) X server windows can live on the same screen as normal Amiga windows. Using the already written Amiga graphics library (which does basically everything an X server needs to do) gets you all kinds of performance wins, because the graphics coprocessor does most of the work for you. The Amiga 500 currently does not have virtual memory... of course it also costs only ~$500. >>Peter da Silva, Xenix Support, Ferranti International Controls Corporation. >Matt Kennel mbkennel@phoenix.princeton.edu -- Marc Mengel mmengel@cuuxb.att.com attmail!mmengel ...!{lll-crg|att}!cuuxb!mmengel
jonnyg@umd5.umd.edu (Jon Greenblatt) (05/05/89)
In article <1306@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
rom article <4037@ficc.uu.net), by peter@ficc.uu.net (Peter da Silva):
)
))And given that 386 UNIX machines with enough RAM to run X typically burn a Meg
))for disk buffers, complaining about a bit of backing store doesn't really make
))a whole lot of sense.
)
)A bit of backing store? Lets see, my default xterm window size is
)80x60 using an 8x13 font so that is 499200 pixels. On a machine with
)32 bits/pixel (yes, such machines exist and run X) thats 1,996,800
)bytes or 1.95 megabytes.
I do not know how xterm is handled but when you specify backing
store, you also specify the number of planes to back. Given that xterm
is monocrome, it uses 1 color plane. So a 80x60 xterm using an 8x13 font
that is 499200 pixels and at 1 bit per pixel thats 62400 bytes.
Applications should not depend on backing store, it should
just enhance applications optionaly. Many machines will run out of memory if
even a small set of apps need backing store.
JonnyG.new@udel.EDU (Darren New) (05/05/89)
In article <8904281155.AA02450@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU writes: > > That's an interesting comparison, since the Amiga windowing system does > guarantee a backing-store for all windows. If Intuition can do it, why > not X? > >How does Intuition do it? Does it pop up a message: "Please insert floppy >number 137, I need to save/retrieve some backing-store bits" ? They must be >trading off something somewhere. For example, do they guarantee backing-store >regardless of how big you later make the window? Does that mean they >preallocate max-sized memory chunks for every window created? Is there a >small limit to the number of windows that can be created? Or does the >"guarantee" mean the system will crash unexpectedly at some point? There are three kinds of Amiga windows. "Simple" windows are like X-windows, which need to be refreshed when exposed. "Smart" windows need only to refresh a window when it is made larger. When the window is covered and then revealed, the revealed portion is displayed from the "backing store" which is actually main memory. (I.e., never swap to disk.) "Super-Bitmap" windows have preallocated bitmaps when opened, and the portion visible "through" the window is copied to the screen memory. When a Smart window is overlapped, the obscured potion is saved to newly allocated memory. The other two obviously don't need on-the-fly allocation. If the memory can't be allocated, as far as I know all that happens is that you position the window and it fails to move. I.e., attempts to move windows when there is insufficient memory result in the move request being ignored/cancelled. Disclaimer: I just work here. -- Darren
jim@EXPO.LCS.MIT.EDU (05/05/89)
>> A bit of backing store? Lets see, my default xterm window size is >> 80x60 using an 8x13 font so that is 499200 pixels. On a machine with >> 32 bits/pixel (yes, such machines exist and run X) thats 1,996,800 >> bytes or 1.95 megabytes. > > I do not know how xterm is handled but when you specify backing > store, you also specify the number of planes to back. Given that xterm > is monocrome, it uses 1 color plane. So a 80x60 xterm using an 8x13 font > that is 499200 pixels and at 1 bit per pixel thats 62400 bytes. Nope, the previous poster was correct. You're mixing up the number of colors (and you forgot one) with the number of planes it takes to display a color. The VT window in xterm can have up to three separate pixel values in it: foreground, background, and text cursor. These colors are represented in the frame buffer by arbitrary pixel values, so backing store would have to save the planes representing the union of all three pixel values. Since a fair number of frame buffers are "Z-oriented" (they store all of the bits of a pixel contiguously in memory) instead of "XY-oriented" (they store each plane separately), trying to save a subset of planes isn't guaranteed to be any cheaper than saving all of them. Jim Fulton MIT X Consortium
peter@ficc.uu.net (Peter da Silva) (05/06/89)
In article <1306@esunix.UUCP>, bpendlet@esunix.UUCP (Bob Pendleton) writes: > A bit of backing store? Lets see, my default xterm window size is > 80x60 using an 8x13 font so that is 499200 pixels. On a machine with > 32 bits/pixel (yes, such machines exist and run X) thats 1,996,800 > bytes or 1.95 megabytes. And any half-bright implementation of layers on a machine with that deep a display should track the colors used. An XTERM window uses at most four colors (fg, bg, cursor, and pointer), so if it backs up more than two bitplanes it's horribly inefficient. So, it's really a quality of implementation issue. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
jim@EXPO.LCS.MIT.EDU (05/06/89)
> And any half-bright implementation of layers on a machine with that deep > a display should track the colors used. An XTERM window uses at most four > colors (fg, bg, cursor, and pointer), so if it backs up more than two > bitplanes it's horribly inefficient. Again, this mixes up number of colors (3, pointer is stored separately) with the number of bits in the union of the necessary (and arbitrary) pixel values. > So, it's really a quality of implementation issue. No, it's really a boolean arithmetic issue.
doyle@b11.ingr.com (Doyle Davidson) (05/11/89)
In article <4089@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes: > In article <1306@esunix.UUCP>, bpendlet@esunix.UUCP (Bob Pendleton) writes: > > A bit of backing store? Lets see, my default xterm window size is > > 80x60 using an 8x13 font so that is 499200 pixels. On a machine with > > 32 bits/pixel (yes, such machines exist and run X) thats 1,996,800 > > bytes or 1.95 megabytes. > > And any half-bright implementation of layers on a machine with that deep > a display should track the colors used. An XTERM window uses at most four > colors (fg, bg, cursor, and pointer), so if it backs up more than two > bitplanes it's horribly inefficient. That is of course assuming your 4 colors landed on just two planes (i.e. color indices 0 1 2 3) They could be indices 5, 19, 31, and 4923!!! Or what about some sort of 32 bit true-color display. I suppose you could keep track of the color values used by a window in a private structure and do some sort of mapping when you did the backing store. Ouch! And what happens when the client decides it wants another color. Malloc another private bit plane or something. And what if the client... Hmmm... Maybe that's why we kinda decided not to do backing store in our server [yet] (Not to mention that 1.95 megabytes just to save 80x60 (4800 bytes) of data :-) ------------------------------------------------------------------ Doyle C. Davidson | Intergraph Corp. | These comments are... Workstation Graphics Standards | 1 Madison Industrial Park | \\ / Huntsville, AL 35806 | \\/ (205) 772-2000 | /\\ clusively my own. | / \\ ..!uunet!ingr!b11!doyled!doyle | ..!uunet!ingr!doyle | ------------------------------------------------------------------