Sun, 15 Jul 2007

Speed

So this clock program displays an analog clock (see picture), and a digital clock, and you can switch between them. The analog clock face is stored in a PICT resource, but the hands are drawn every second, of course.

I didn't have a good grasp of the speed of this process, so in my debug build, I calculate how long it takes to draw the analog clock (not including the extra time to copy it from the offscreen buffer onto the screen). The simplest way to measure sub-second time on the Plus is to use "ticks". A "tick" is 1/60th of a second. My routine takes about 35 ticks, meaning that it takes a little more than half a second to draw the clock.

This bothered me, and I wanted to see if I could get that time down. I remembered the clock face picture. It's a 512 x 342 bitmap in a PICT, and DrawPicture basically just does a full-screen CopyBits to draw it. I know CopyBits takes a while, so I thought that I might replace it with direct calls to QuickDraw -- I'd programmatically draw the entire analog clock, and not just the hands.

I spent a couple of nights on this. It was a pain in the neck to replicate the clock face exactly. I'd drawn most of it in ClarisWorks, although I drew the angled marks on the clock face (for :05, :10, :20, and so on) programmatically to get the angles right. Then I took a screenshot and pasted them in. Anyway, getting everything to look right programmatically was a pain.

So I plugged in my new routine and ran the program: 55 ticks. It was now taking almost a whole second to draw the clock, and the second hand was visibly jumping two seconds at a time at places. Ugh.

Maybe 35 ticks ain't so bad...

posted at: 04:02 | path: /geek/hpc | permanent link to this entry