Category: Wear OS

I’ve been a fan of Flutter and Dart for some time. Recently I purchased a Wear OS smart watch and I’m interested in how well a Flutter game will perform on it.

My watch is a Mobvoi Ticwatch Pro 5. It’s a beast, with 2GHz of Ram and a low-power 1.7GHz quad-core GPU. The display is a gorgeous 1.43″ 466*466 AMOLED screen. You can read the full specs here.

My background is in game development for mobile – starting back in the day before iOS and Android existed – when devices had huge limitations in terms of CPU, ram, storage, network, screen size – you name it! I love working within limitations like these. They represent a special challenge for game design and development!

I’m working on a prototype bullet-storm shooter with lots of bullets and particle effects to really try and see what the limitations of Flutter running on Wear OS are. I’m using a modified version of the Flame engine.

Limiting the frame rate in Flame

Flame works by calling an update function as often as possible. On desktop this tends to be around 120fps. On the Ticwatch it’s 60fps. To test the effect of different frame rates I modified the update function to limit the frame rate. Something like this:

double _renderPeriod = 0.0;
double _elapsedTime = 0.0;

/// Set the maximum framerate for the game
set maxFPS(double? fps) {
  if (fps == null) {
    _renderPeriod = 0.0;
    return;
  }
  _renderPeriod = 1.0 / fps;
}

/// Ensure the framerate doesn't exceed maximum
@override
void updateTree(double dt) {
  _elapsedTime += dt;
  if (_elapsedTime >= _renderPeriod) {
    super.updateTree(_elapsedTime);
    _elapsedTime = 0.0;
  }
}

Testing the effects of different frame rates

To perform the tests I repeated these steps:

1. Charge the watch to 100%
2. Set the framerate
3. Run the game for exactly 30 minutes
4. Check the battery level

Here are the results:

Analysis of results

Changing the frame rate made no difference to the battery drain.

I was initially surprised, but then I quickly realised that this made sense. My testing is flawed.

My tests are not changing the fundamental framerate of the app. Under the hood, graphics are still being rendered to the screen at the same rate.

It’s just my higher level update function that is being limited. It performs physics calculations and moves objects around, but it’s not responsible for the actual rendering. So while the animation is choppy and jumpy, the rendering is still happening at the same rate.

Here’s an image to illustrate. It shows 10 frames being drawn while the ship is rotating:

As you can see:

• In both cases, the underlying code is updating the frames at the same rate
• But when the fps is being limited (incorrectly), only the animation (rotation) is being limited.

However, this next image shows what the intended effect of reducing frame rate should be:

So back to the drawing board in this one.