lee@TIS.COM (Theodore Lee) (02/17/90)
In my spare time I've been browsing through the toolbox references and TML examples, gearing myself up for doing some *REAL* programming. One thought has come to mind -- is there any usual way of updating windows without completely regenerating them? Suppose you have a big window that took a lot of calculating to fill. A small NDA window gets opened up and covers up, say, a quarter of the window. When the NDA window goes away, moves, or is covered, presumably the main window gets a window update event. Rather than redrawing the main window (or even just that part in the update region) is there a way of saving the pixels that got covered up by the NDA's window and just restoring them? (No, I haven't read all the technotes yet; I suppose, as usual, the answer is in there somewhere.) (I was just picking an NDA window as an example; same question arises in general, e.g., even when just a menu drops down or when another window gets opened.) Its clear you could have the window content procedure save a copy of all the pixels in the window when it's done and use that to redraw (if nothing has changed), but I wondered if there was any built-in support for that kind of thing that I've missed, especially something that squirreled away only the pixels in the region being covered. lee@TIS.COM
shatara@memit.enet.dec.com (Chris Shatara) (02/17/90)
In article <9002161625.AA26906@tj.tis.com>, lee@TIS.COM (Theodore Lee) writes... >.... >One thought has come to mind -- is there any usual way of updating >windows without completely regenerating them? Suppose you have a big The answer is yes! When you define the window with the window paramater block, you define the wContDefProc (window content definition procedure) as a pointer to your content drawing routine: wContDefProc := @DrawWindow {DrawWindow is the procedure which draws the contents of the window} To make things go faster, you should have your window drawing procedure take into account the visible region of your window (assuming your using scroll bars and not all the window is visible at a time). This takes some thinking but saves a bunch of time. This has worked quite well for me and will do what you want. More sophistication can be added by only dealing with the update region but I haven't found it necessary to do this. Hope this helps...Chris ============================================================================= | Chris Shatara | Internet: shatara@memit.enet.dec.com | | Opinions expressed are | DEC Easynet: memit::shatara | | mine and mine only! | UUCP: ...!decwrl!memit!shatara | =============================================================================
dlyons@Apple.COM (David A. Lyons) (02/20/90)
In article <9002161625.AA26906@tj.tis.com> lee@TIS.COM (Theodore Lee) writes: >In my spare time I've been browsing through the toolbox references and >TML examples, gearing myself up for doing some *REAL* programming. >One thought has come to mind -- is there any usual way of updating >windows without completely regenerating them? Suppose you have a big >window that took a lot of calculating to fill. [...] Someone else posted an answer to this last week, but I don't think they answered the question you were really asking. I think you're looking for a technique like this: Do your drawing to a QuickDraw port that isn't on the screen. When your window needs to be updated, copy part of the image from your offscreen grafport to the window. This way the time-consuming generation of the image is just done when necessary. To create an off-screen grafport, allocate 170 bytes of memory somewhere, call OpenPort on it, allocate enough memory for your offscreen pixelmap, set up a LocInfo record for your offscreen pixelmap, and use SetLocInfo to cram that LocInfo record into your port. (You may want to do a big EraseRect to clear your offscreen pixel map to the port's background pattern; I don't remember whether the background pattern is initialized to white for you with OpenPort or whether you have to set it yourself first.) When your window's content-draw procedure gets called, just do a PPToPort from the offscreen pixel map to the window (which is the current port, conveniently enough). If you need to make changes to the window's contents, do the drawing in the offscreen port and do an InvalRect or InvalRgn on the window to force an update. (Or do the same drawing over again in both ports. Whatever.) -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.