Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!apple!keith From: keith@Apple.COM (Keith Rollin) Newsgroups: comp.sys.mac.programmer Subject: Re: Saving area under dialog boxes (Re: WingZ) Message-ID: <29827@apple.Apple.COM> Date: 29 Apr 89 05:46:20 GMT References: <598@eutrc3.UUCP> <1774@ccnysci.UUCP> Organization: Apple Computer Inc, Cupertino, CA Lines: 62 In article davidl@intelob.intel.com (David Levine) writes: >In newsgroup comp.sys.mac, in article aberg@math.rutgers.edu (Hans Aberg) writes: >> >(Would it be a stupid idea to BitCopy the area where the dialogue box >> >will apear into an array, then display the dialogue box, remove it >> when >> >done and BitCopy the array back to the window? Would have saved me >> >another 2 minutes) >> >> >>Not to argue with the other points (I don't have WingZ), but this is definitely >> >>a Terrible Bad Awful Idea, and the Apple Thought Police will lock you up if >> >>you do this. >> >> The Finder, and the earlier systems actually work like this: By >> temporarily saving the portion where a dialog box or or menu pops up, >> and then copying it back again. In a multitasking environment this >> does not work, because some other application may decide to change >> the graphics in the area temporarily saved. This is in fact reason to >> why all processes used to start hanging when pressing the mouse button >> in earlier systems. > >OK, I've been following this discussion for a while, and I don't >understand the problem. Yes, it would be a Bad Idea to CopyBits from >the SCREEN to a buffer and then restore after the dialog goes away. >But the original poster seems to have been talking about the >application copying the affected area of ITS OWN WINDOW to a buffer >and then restoring ITS OWN WINDOW. What could be wrong with that? It >seems a fairly standard technique. (Actually, an application with >complicated drawings should keep a copy of its window in an offscreen >bitmap at all times, and blit it to the screen whenever it's needed. >Right?) > Saving data from your own window into an offscreen buffer is not much of a problem _right now_. It should even work in the forseeable future. However, I would recommend against it in favor of doing it the other way around; keep the master image in an offscreen buffer, and refresh from it exclusively. One of the things that some people have been clamoring for on the Mac is pre-emptive multitasking, rather than the GNE/WNE/EA switching that goes on now. Imagine a scenario where this is actually implemented. The program in the background is about to put up a dialog box or some such, and is stashing the bits in the window away somewhere in memory. However, at the same time (or close to it), the user is futzing around in the Finder, dragging icons around. If the user drags the icon outline over the window that is being cached into some offscreen buffer, that outline will get stored also. When the dialog box is put away, then window contents, plus the icon outline will be put back. A better approach is to keep your master image in an offscreen buffer in the first place. The first advantage of this is that you won't have the afore- mentioned problem. The second is that you will be able to cache more than just what appears in the window; by caching a full page or three, you can get significant increases in scrolling. (The third advantage is that the demand for RAM goes way up and Apple gets to sell more. :-) ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions