I think that DispatcherTimer
is not your best ally for this task. The class is by no means designed to execute actions at precise intervals.
I'll try to better explain myself: even if the DispatcherTimer
, as its name suggests, dispatches actions timely and with a great precision, the dispatched actions will be queued and then executed when the underlying GUI
thread decides to process them.
Normally, a GUI
thread has a resolution of around 8ms
(it's an approximation, but I don't think we need to measure this right now)... and you are using a starting Interval
of 80ms
that is going to decrease over time until it probably goes beyond that tolerance limit of 8ms
or so. In the meanwhile, you are also repainting your interface (or part of it) over and over and this impacts the performance and the responsiveness of the GUI
even more: if the GUI
thread is busy repainting and that requires more than the Interval
value to be accomplished, the next dispatched action will be processed only once the GUI
thread completes the undergoing task.
If you need a more precise scheduling, avoiding hangings / losses of responsiveness / delayed actions, you need to use a timer class that runs in background like System.Threading.Timer
(google for SyncronizationContext
, that would be helpful) or System.Timers.Timer
.
On the top of that, never play with intervals when showing a change in speed. Work with a fixed interval and increase/decrease the movement "size" in pixels. You should be able to calculate the delta without problems. Just to make things clearer: if I want to slow that the speed of an object doubled, I don't half the timer interval that draws the object, but I double the amount of pixels my object traverses at each step.