Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven.umd.edu!cs.wvu.wvnet.edu!cerc.wvu.wvnet.edu!blackwater!vrm From: vrm@blackwater.cerc.wvu.wvnet.edu (Vasile R. Montan) Newsgroups: comp.sys.mac.programmer Subject: Optimizing animation processing speed Message-ID: <1776@babcock.cerc.wvu.wvnet.edu> Date: 18 May 91 01:46:10 GMT Sender: news@cerc.wvu.wvnet.edu Reply-To: un020070@vaxa.wvnet.edu Lines: 33 I am in the process of writing a program that does some pretty complicated animation. In the version of the program I've got now, things are just running too slow. I've got to figure out how to make things run faster. (I'm already on an 030 machine with a math coprocessor, so running this program on, say, a Plus would be just intolerable.) I'd like to run my scheme past you; could you all please suggest places where I could speed things up? In this animation, I am moving icons around on the screen. I have two offscreen bitmaps. The first offscreen contains the background art, which is slow to draw; this way, I only have to draw it once. I continually CopyBits this whole bitmap into the second bitmap. I draw the icons the second bitmap, then copyBits the second bitmap onto the screen. This whole process happens every event loop. (Slow as this sounds, I have reason to believe that this is actually not the big time-consumer.) Each time I plot an icon, I GetIcon it, then draw it using copyBits, then ReleaseResource it. Now, if I'm not mistaken, this doesn't actually purge the icon from memory, right? If something else needs the memory it will write over it, but if nobody needs the memory, the icon will hang around until the next cycle, and GetIcon will just give me a handle to the icon in memory, right? In doing the calculations for the animation, I frequently refer to complex data structures by handles. Is this a particularly slow way of doing things? Could I speed things up appreciably by locking the handles and using more Pascal WITH statements? Any suggestions? --Kurisuto un020070@vaxa.wvnet.edu