Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!cs.umn.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@mcs-server.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: How do you draw lines into the current view for Rubberbanding Message-ID: Date: 4 Jun 91 06:14:03 GMT Article-I.D.: mcs-serv.SCOTT.91Jun4011403 References: <507@heaven.woodside.ca.us> <836@rosie.NeXT.COM><4043@ssc-bee.ssc-vax.UUCP> Organization: Gustavus Adolphus College Lines: 72 Nntp-Posting-Host: mcs-server.gac.edu In-reply-to: dmg@ssc-vax's message of 30 May 91 22:19:33 GMTLines: 72 In article <4043@ssc-bee.ssc-vax.UUCP> dmg@ssc-vax (David M Geary) writes: ] 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. The best way to implement the above on a NeXT is to use 4 actual _windows_ that overlay the selection. This is what's used in the AppKit for the Window resizing rubber-banding, and a similar technique is used in InterfaceBuilder to draw the connections that go between windows. Basically, you have 4 narrow windows, 2 horizontal, 2 vertical. Then, you move them around as needed. This is relatively flicker-free (well, you can't get much less, as anything you do will, in the end, depend on Display Postscript, and this should be about as good as it gets for rubber-banding.) To get an inkling of the method to use, look in /usr/lib/NextStep/windowPackage.ps - therein resides code that's loaded into the server that can be used to check out system-wide windows for such a use. If you can wait, I've been working on a modified Window class which uses this for its resizing, so hopefully there will be a real example out there at some time in the future. Note that this is probably not a NeXT-supported method of rubber- banding (ie, using the code in the windowPackage). But, the technique should work fine, regardless. Lastly, a point for Mr King - the instance drawing he is speaking of is generalized - it's not limited to rubber-banding. You can draw arbitrary postscript as the instance drawing, and then have it go away when you tell it to. That's nice for some things - unfortunately, you do lose either WRT the look of the drawing (flicker), or memory. Fortunately, many rubber-band effects are rectilinear, so that can be worked around in some special cases . . . Later, -- scott hess scott@gac.edu Independent NeXT Developer Graduated GAC Undergrad! Note: I have moved home for a time. My email address will still be valid. Any SnailMail should be redirected, along with phone calls. At the least, my parents can tell you how to get hold of me, or forward any mail . . . Old: PO 829, GAC, St. Peter, MN 56082 (507) 933-8466 New: RR#4 Box 227 Pipestone, MN 56164 (507) 825-2788