Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ingr!b11!doyle From: doyle@b11.ingr.com (Doyle Davidson) Newsgroups: comp.windows.x Subject: Re: Handling exposures / R5 wish-list, etc (was Re: ghostscript2.0) Message-ID: <8826@b11.ingr.com> Date: 25 Sep 90 18:50:49 GMT References: <9009201038.AA05265@Larry.McRCIM.McGill.EDU> <10264@nfs4.rl.ac.uk> Organization: Intergraph Corp. Huntsville, AL Lines: 106 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 | ------------------------------------------------------------------