Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!mips!atha!aunro!alberta!brazeau.ucs.ualberta.ca!unixg.ubc.ca!ubc-cs!uw-beaver!fluke!ssc-vax!dmg From: dmg@ssc-vax (David M Geary) Newsgroups: comp.sys.next Subject: Re: How do you draw lines into the current view for Rubberbanding Message-ID: <4043@ssc-bee.ssc-vax.UUCP> Date: 30 May 91 22:19:33 GMT References: <507@heaven.woodside.ca.us> <836@rosie.NeXT.COM> Sender: news@ssc-vax.UUCP Reply-To: dmg@ssc-vax.UUCP (David M Geary) Organization: Boeing Aerospace & Electronics Lines: 51 Peter King writes: ] In article <507@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) ] writes: ]] ]] I'm curious; why isn't instance drawing implemented to avoid flickering in ]] the manner you suggest? It seems that this would be a better ]] implementation, and just as easy, unless I'm missing something. ]] ] You can get a cleaner, snappier look if you ] are willing to pay in virtual memory for the buffered window. In a ] demand-paged system such as NeXT's, using more virtual memory effects the ] performance of the overall system. ] When you do double-buffered compositing for dynamic drawing, you need to ] allocate an off-screen window to hold the on-screen window's current state. ] Let's look at a worst-case scenario: we are writing a Draw like program that ] works in color on the NeXTdimension. An 8.5 by 11 page will take ] 612 pixels * 792 pixels * 4 bytes per pixel = 1938816 bytes ] Almost 2MB for the off-screen window. This will undoubtably cause paging to ] happen. If you have limited physical memory, this may not perform as fast as ] needed. ... Excuse me for jumping in on this thread because I do not own or even work on a NeXT, but having designed my own GUI from the ground up at work, and having implemented rubber banding ... If all you want to do is rubber-banding without the flicker, why allocate an off-screen buffer for the *entire* window? Instead, why not allocate 4 buffers,each of which is one pixel wide by screen width (or height) long: 1 pixel * 792 pixels * 4 bytes per pixel = 3168 bytes 3168 bytes * 4 (one for each line in rubber band rectangle) = 12672 This results in only 12K of ram vs. 2M. This seems quite reasonable to me. After all, it is not necessary to continually save and restore what the rubber banding rectangle *encloses*, just the portion of the screen that the rubber banding rectangle's lines are going to be drawn over. I have used this exact technique on a slow dinasour of a workstation (a Sun 3/60) and I have no flicker at all. Sorry if I'm way off base (see above disclaimer)... -- |----------------------------------------------------------------- | David Geary, Boeing Aerospace, Seattle, WA. | | | | Seattle - America's most attractive city... to the *jetstream* |