Yep - that's what occurred to me on the way to work. Just offering two configurable values - number of zooms to apply at startup (9 is the max - and it really seems more like 8.25 since the last click doesn't zoom much); and number of zooms to apply when entering navigation mose (2 is the max). That is far simpler and less error prone than tracking zooms in/out and trying to maintain that.
I'm mostly comparing it to MapPoint and S&T run standalone. Both use about a steady 40% cpu and are updating much more frequently. The end result is that when travelling in a straight line, the position shown is closer to where the car actually is.
Cpu usage I see is ~20-40% mappoint and ~40-60% autotouch *when* it's doing work (i.e during the spikes). It may just be that you're paying a lot of cost for the graphics rendering in managed (it uses gdi+ and that's not a very cpu friendly piece of code).
One thought I had about perf - can you use MapPoint in way to get various map tiles and do the recombination yourself. I.e. reduce the frequency you need to ask mappoint for a map and potentially reduce the work to rotate it. If you reduced the granularity on the map rotation some, you could be able to re-use the rotated image more often (e.g. when travelling in a straight line) and just keep adding on new bits from the next tile in memory.
The settings hang came back - it only happens when the GPS is connected. When I kill AutoTouch via task manager, MapPoint then crashes.