A good User Interface (UI) has both a high frame rate and a smooth
frame rate, meaning there is no visible jitter in the speed at which
the screen updates. We can animate using our own Thread or a Timer, and we can perform the animation logic
changes just before we paint on a different thread. Which approach
is best at updating the screen quickly and not making logic changes
appear to “lag” due to the painter falling behind?
There are several related performance questions to answer here:
Is Timer.scheduleAtFixedRate(40) or a Thread.sleep(40) faster at animating my GameCanvas?
Is Timer.scheduleAtFixedRate(40) or a Thread.sleep(40) more visibly smooth at animating
my GameCanvas?
How many Threads (or TimerTasks on a single Timer) should I use, including the renderer?
Should I update
the screen model on the same Thread/TimerTask as
the renderer, or a different one?
Let’s first look at the raw test results where one Renderer and
0-3 additional Threads or TimerTasks did some repetitive math (int a = 0; a += 34, repeat 1000 times)
to create processor load.
# threads/ timertasks |
Wake Up Interval (ms) |
scheduleAtFixedRate() |
logic (moveX) in render or “worker” thread/timertask |
FPS with threads |
FPS with timertasks |
Smoothness with threads (related to fps) |
Smoothness with timertasks (related to fps) |
|---|---|---|---|---|---|---|---|
1 |
40 |
yes |
render |
12 |
23 |
quite smooth |
really smooth |
2 |
40 |
yes |
render |
16 |
22 |
quite smooth |
quite smooth |
4 |
40 |
yes |
render |
19 |
22 |
smooth |
smooth |
1 |
40 |
yes |
worker |
12 |
23 |
not very smooth |
really smooth |
2 |
40 |
yes |
worker |
16 |
22 |
not very smooth |
not smooth |
4 |
40 |
yes |
worker |
19 |
22 |
quite smooth |
not very smooth |
4 |
1 |
yes |
render |
19 |
23 |
laggy |
laggy |
4 |
1 |
no |
render |
- |
23 |
- |
smooth |
From these systematic tests, we can see results that may seem surprising:
With Threads, the smoothness and rendering frame rate actually
increased with more worker Threads, so multiple threads
was not a problem in these tests and actually helped visible animation
by apparently decreasing the time slice per Thread when there were more Threads. This is unexpected,
but worth keeping in mind: allocating more Threads may actually make your multitasking UI appear more smooth.
TimerTask.scheduleAtFixedRate(40) adapts well and gives a higher frame rate than a fixed Thread.sleep(40). This is because the Thread version is not dynamically
adapting to the load from other Threads. Thus, to
achieve full 25 FPS, the simple Thread code used
should be improved to sleep not for a fixed 40 ms, but a value less
than 40 ms calculated using System.currentTimeMillis().
With Thread and TimerTask, setting a very high
repetition rate made the UI feel laggy as the Timer tried to keep up with a rate it could not sustain. Thus setting
a fixed rate with Timer works well, but only when
you tune to a lower rate than the maximum, the phone can sustain.
In both cases, you can remove the sensation of display lagging behind
the input if you make your renderer adapt to the current frame rate
rather than blindly assume the requested frame rate will be achieved.
With Thread and Timer, it is a bad idea to put
separate TimerTasks or Threads with
one doing the model updates and another doing the rendering. In both
cases, model updates and similar loads should be done just before
rendering.