Disk Clock 1.5: Smooth Operator

Disk Clock latest 1.5. A very restrained update – martial arts seminar on Sunday and lot of other things Saturday, including a walk in the park (yay, weather forecasts for dodging deadly-cold.) Attempted to fix animation pops yet again, and dropped the file size by removing an image.

Would You Just Go Away Already?

The main thrust of my work was to eliminate the animation pops/jumps seen under certain conditions. I’ve made several attempts to fix this, and hopefully I’ve now understood the problem well enough to stop it out. Pops come from a couple of sources.

Early Animation Exit

A legacy from the old stateless animation system, the disk would switch over to direct-set mode when the change in position got small enough. You have to be careful with this, because if it’s set too small, fast disks such as the seconds (which is actually called a minute for it’s full range) will animate on every step – a bug I’ve fixed in the past. One thing I hadn’t done yet was simply not make the size check if the animation was still running.

Animation Never Starts

There was a check in the animation engine to avoid animating very small changes. However, the old threshold of 0.01 was still quite visible. It appears that threshold is around 0.005 (0.5%). Interestingly, looking back at now, a degree is around 0.0027. In any case, the animation start epsilon has been dropped to 0.001.

Size Matters

Changes are in fact more visible on the larger disks. I extracted a perimeter calculation to it’s own method, and started poking at it. Changes of around 1 pixel of perimeter are visible – actually even less, I presume do to subtle changes in the angle of marks.

The Data Is Bad

I’d been using a particular attribute of disks called a calcUnit. It’s generally the next step down – seconds in minutes, minutes in hours etc. Some particular sore spots were the 4-hour disk, enumerated in minutes – up to two minutes could pass before it started animating, and the moon, enumerated in days – which would jump for less than two days, and was usually seen every day. Worse, while it hasn’t yet come up in normal use, this same unit is used as the minimum update frequency. If you used the moon as base for instance, it would update once a day, and jump about 1/29th every time.

You can’t just make things animate easily – sometimes it has to jump to keep the update frequency sane, such as with the minute disk which ticks every second – wonderful as Javascript/Canvas is, constant updates have a very noticeable effect the CPU load.

Nuke ‘Em From Orbit, It’s The Only Way

The solution is rather brute force. The delay factor (already wrapped in a function to handle time scaling) was modified to be based on 1 pixel of perimeter, within certain limits, such as the sane update frequency. When updating position, the change in position is translated back to time and compared to the nominal update frequency. The effect is like “movement represents 2 minutes, but 1.3 minutes is considered a visible change”


With update glitches dependent on whether an updated crossed the line or not, my random-skip testing method was insufficient. I split it into a constant and random part, and also made it use the time unit DSL.

Image Economy

The change a few versions back which prevented position changes while scaling broke the spin-down effect of the logo disk. While pondering that I realized that with the back-face image I have now, I could get the static image for loading by simply building it into the back image. Now I don’t even need a logo disk and it’s attendant special cases. I used a 50% translucent logo (baked into the image) so that it could also serve as s the rear-face backdrop. That allowed me to remove an image and drop 40k off the download size.

Posted Sunday, December 21st, 2008 under Devlog.

Comments are closed.