caag@inf.rl.ac.uk (Crispin Goswell) (09/24/90)
In article <9009201038.AA05265@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU writes: >> One thing that gs2.0 X previewer does do it paint to both a pixmap >> and the display. That's kind of redundant, > >Not entirely; it makes handling Expose events much simpler. > >> but prompts the question [...]: > >> How does one making ones own backing pixmap that works like >> backingstore? > >It's not really difficult, but it's a bit tedious. Just create the >pixmap, and then to draw something do > > - draw it to the pixmap > - set the window's background to be the pixmap > - draw it to the window > >The order is necessary to avoid races with exposures, and the constant >resetting of the window's background is necessary because the server is >allowed to make a copy of the pixmap when you set the background. (If >the server is copying the pixmap, this is also likely to be slow.) > You don't have to draw everything twice - you can use XClearArea instead. We have a local toolkit, which we ported to X11. It has several ways of managing exposures. One of the options is to set the window background to a Pixmap the size of the window then draw on the pixmap. When we want a series of graphics requests to become visible, we use XClearArea to cause the bounding box of the graphics drawn to be copied onto the window from the background tile. We track the bounding box of the graphics requests ourselves (our toolkit is window-system independant, so all graphics requests come through the toolkit, so this is easy). When exposures happen, the server clears the exposed regions to the background tile, which is always the picture we wish to see. We can thus ignore exposure events. Besides being an ugly trick, there are three problems with this approach: The most serious is that a given server may not have sufficient Pixmap space available, or may not be able to tile quickly with large Pixmaps. The MIT R4 server seems to tile large pixmaps much more slowly than it can copy areas (the performance for large pixmaps *should* be almost the same on a dumb frame buffer, but isn't). A given server may also copy the background pixmap (as mentioned above). Another problem is that updates happen prematurely if a window is exposed and the background Pixmap is not copied. We find we can live with this, given the performance advantage (and better appearance) of instantaneous exposure processing. Moving windows wholly, rather than with wire-frames makes this more noticeable. The third problem is that most graphics processors can display only on the visible frame buffer, or a double buffer, so X must simulate their behaviour (slowly) for Pixmaps. This is a problem with most graphics processors. It turns out that if drawing a new picture is more expensive than copying a Pixmap the size of its bounding box, then this technique works well. Our toolkit normally only copies to the display just before receiving user input, with the result that changes in the display appear instantaneously and without flicker. We feel that this adds greatly to the perceived quality of the user interface. Our toolkit has another option (configuration parameter) which allows the pixmap to be copied to the window using exposure events. We use this option on the MIT R4 server because the XCopyArea is sufficiently faster than the background clear-to-tile that it more than makes up for the delay in exposure event processing. We looked at making the double-buffering extension in R4 an option for our toolkit, but the software simulation in the MIT R4 server copies the entire pixmap, rather than just the bounding box of the changes, and thus performs much more slowly than our own method. There is an interesting conjunction between backing store and double buffering which our toolkit uses: with double buffering, you need an off-screen copy of everything that is visible. with backing store, you need an off-screen copy of everything that is *not* visible. This adds up to exactly one copy of the entire window, so our toolkit provides exactly that. The backing store and double buffering code in the MIT server could be made much simpler if they cooperated in this way, as they have in window systems of the past. >I would like to see a something that could be passed in place of the >current backing-store hint that says "I want backing-store, and give me >an error if you can't commit to doing it" instead of the current >scheme, which allows the server to decommit backing-store at any time >for any reason. I will re-inforce this: the current attitude taken by the X Protocol is that the client should not need to be aware of backing store; this is a server-based view. The developer-based view is that applications care about things which affect performance and appearance (which backing store clearly does). Since it is possible to simulate backing store (with mixed efficiency) if it is not present, an application will want to know whether such simulation is necessary. Relying on servers to be great (or aspire to greatness) is not enough. A related possible extension (for R5?) would be one which reports the relative performance of different features of servers. One problem many face at the moment is that a technique which performs well on one server is too slow on to be tolerable on another. This is an issue of performance portability, which in many cases is as important as feature portability. [Danger: colourful metaphor ahead] As colour machines are being increasingly regarded as superior to monochrome, the use of cheap and cantankerous graphics processors will make the cliffs and ravines of the performance curves ever more treacherous for the unwary. Taming this rugged landscape may be achieved using a resource manager and performance database, though clearly some standards are necessary. While I'm adding to the R5 wish list, how about allowing double/multi buffering to be simulated more effectively on PseudoColor hardware by altering the hardware colour map, as done by the ico demo program. This could be done by adding a switch to the server to make it behave like a double buffered screen with half the number of bitplanes per buffer. A better method might be to integrate this into the Visual mechanism somehow. BTW, in case anyone is wondering, the features of the toolkit described above explain why RALpage (aka xps) does not respond to exposure events. Our internal toolkit can simulate backing store - the current X11 driver does not. RALpage also has a side-effect on the "flush" primitive, which forces the window to be updated. This is used by the interactive reader to ensure that the display is correct before prompting the user. Name: Crispin Goswell |-------|__ Informatics Department UUCP: {... | mcvax}!ukc!rlinf!caag | Tea | | Rutherford Appleton Lab JANET: caag@uk.ac.rl.inf \ Mug /_/ Chilton, Didcot ARPA: caag%inf.rl.ac.uk@nsfnet-relay.ac.uk \_____/ Oxon OX11 0QX, UK "To avoid trouble. I quickly abolish fires, garbage, and also mail, which after all never brings anything but problems." - Italo Calvino -- Name: Crispin Goswell |-------|__ Informatics Department UUCP: {... | mcvax}!ukc!rlinf!caag | Tea | | Rutherford Appleton Lab JANET: caag@uk.ac.rl.inf \ Mug /_/ Chilton, Didcot ARPA: caag%inf.rl.ac.uk@nsfnet-relay.ac.uk \_____/ Oxon OX11 0QX, UK "To avoid trouble. I quickly abolish fires, garbage, and also mail, which after all never brings anything but problems." - Italo Calvino
doyle@b11.ingr.com (Doyle Davidson) (09/26/90)
Disclaimer: The following comments are my personal view of various X graphics techniques and are not intended to be flamable :-) In article <10264@nfs4.rl.ac.uk>, caag@inf.rl.ac.uk (Crispin Goswell) writes: > In article <9009201038.AA05265@Larry.McRCIM.McGill.EDU> mouse@LARRY.MCRCIM.MCGILL.EDU writes: [Various comments about drawing to a pixmap and the copying to the window] > We have a local toolkit, which we ported to X11. It has several ways > of managing exposures. > > One of the options is to set the window background to a Pixmap the size > of the window then draw on the pixmap. When we want a series of > graphics requests to become visible, we use XClearArea to cause the > bounding box of the graphics drawn to be copied onto the window from > the background tile. Ugh!! All you application people, please think twice before doing this! How complicated is what you are drawing? This technique is great for mandelbrot programs and such but can be very abusive of server resources and may not work well on all machines. Not every machine in the world has a bit mapped display and I think that you may find this approach does not work as fast for pipelined graphics CO-processors. Sending a few dozen drawline/fill/text commands down the pipeline is much more efficient than jamming several kbytes of pixmap data. I have seen certain workstations criticized on several occasions where it was really due to the programmer's technique. It's not hard to make a Monochrome X terminal humble a much more expensive 3D-24 bit graphics box in the price/performance war for certain operations. It does make me examine certain areas of our server and try to improve its performance though!!! > Besides being an ugly trick, there are three problems with this approach: > > The most serious is that a given server may not have sufficient > Pixmap space available, Agreed. X Terminals and low memory workstations are most damaged by this. > The third problem is that most graphics processors can display > only on the visible frame buffer, or a double buffer, so X must > simulate their behaviour (slowly) for Pixmaps. This is a > problem with most graphics processors. Correct. But once again, is it really necessary to draw to the pixmap? I agree is probably makes life easier sometimes. > It turns out that if drawing a new picture is more expensive than > copying a Pixmap the size of its bounding box, then this technique > works well. Our toolkit normally only copies to the display just > before receiving user input, with the result that changes in the > display appear instantaneously and without flicker. We feel that this > adds greatly to the perceived quality of the user interface. Surely this is true for the box that you are developing on but may or may not be true on others. > A related possible extension (for R5?) would be one which reports the > relative performance of different features of servers. Cool idea. Imagine the coding mightmare that would follow though. I guess a lot of the problem is once again forcing the hardware to fix the software and not the other way around. One of these days, someone will write the software first!!! X terminals are doing a pretty good job of this. > One problem many > face at the moment is that a technique which performs well on one > server is too slow on to be tolerable on another. This is an issue of > performance portability, which in many cases is as important as feature > portability. I couldn't agree more. > While I'm adding to the R5 wish list, how about allowing double/multi > buffering to be simulated more effectively on PseudoColor hardware by > altering the hardware colour map, as done by the ico demo program. So why not do it in the software where one can get whatever he wants? There is nothing keeping someone from doing this. > Name: Crispin Goswell |-------|__ Informatics Department > UUCP: {... | mcvax}!ukc!rlinf!caag | Tea | | Rutherford Appleton Lab > JANET: caag@uk.ac.rl.inf \ Mug /_/ Chilton, Didcot > ARPA: caag%inf.rl.ac.uk@nsfnet-relay.ac.uk \_____/ Oxon OX11 0QX, UK Crispin (cool name!) makes some very good points (IMHO). I have seen a lot of junk code and a lot of very good code. I would like to see someone write a book on good X programming techniques (if there is any such orthogonal beast) that they have managed to collect. Kind of like "Foley - Van Dam". Doyle (climbing down off of my soapbox now before I fall off) Davidson ------------------------------------------------------------------ Doyle C. Davidson | Intergraph Corp. | These comments are... Workstation Graphics Standards | 1 Madison Industrial Park | Huntsville, AL 35806 | (205) 730-2000 | X-clusively my own. | ..!uunet!ingr!doyle | ------------------------------------------------------------------