Path: utzoo!attcan!uunet!mcsun!ukc!warwick!rlnfs4!caag From: caag@inf.rl.ac.uk (Crispin Goswell) Newsgroups: comp.windows.x Subject: Handling exposures / R5 wish-list, etc (was Re: ghostscript2.0 (was Re: fix to font cacheing in ralpage postscript viewer)) Message-ID: <10264@nfs4.rl.ac.uk> Date: 24 Sep 90 15:08:19 GMT References: <9009201038.AA05265@Larry.McRCIM.McGill.EDU> Reply-To: caag@inf.rl.ac.uk (Crispin Goswell) Organization: Rutherford Appleton Laboratory, Informatics Department, U.K. Lines: 159 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