FPS Gameloop, game vs flutter

[wolfenrain]

Based on the discussion in #1582 I am opening this discussion here to report any findings we have or ideas related to the above given title.

The current problem that we are having is that if you would do the following code:

class FpsComponent extends Component {
  double fps = 0;

  @override
  void update(double dt) {
    fps = 1 / dt;
  }
}

The fps would not be reported correctly compared to the Flutter performance view. To be more exact, from my own testing, it always reports in sort of increments (60, 30, 20, 10) but never any precise number.

For context: the internal gameloop uses a Timer (which is backed by scheduleFrameCallback) to ensure our loop works. On each callback we call game.update with the new delta and after that we set the painter to repaint.

[oloshe]

I think I want them both

[munsterlander]

So interesting that this conversation is occurring at the same time we are discussing the opacity issue. @ufrshubham may have to chime in on the dt issue vs fps. Either way, because there is rounding involved based on dt, that's where I think the issue is in opacity bug. I think these are connected but I could be off. Sorry having trouble putting the thought together concisely.

[spydon]

So interesting that this conversation is occurring at the same time we are discussing the opacity issue. @ufrshubham may have to chime in on the dt issue vs fps. Either way, because there is rounding involved based on dt, that's where I think the issue is in opacity bug. I think these are connected but I could be off. Sorry having trouble putting the thought together concisely.

I'm fairly sure that these two are not related, the OpacityEffect bug is luckily contained within that effect (otherwise all other effects would have been affected too).

[munsterlander]

Sorry, I didn't explain what I meant well. I didn't mean related in code but more related in the aspect of dt is variable, i.e. not constant, where other engines have a fixedUpdate method or such. Opacity is varying because of rounding based on dt / progress which is coming from the loop. I guess I meant like very roughly related, 😆

[ufrshubham]

I don't think delta time being variable is the root cause for the bug with OpacityEffect. The fixed update methods in other engines are exposed to allow users to hook-in their physics related code into the physics loop.

[munsterlander]

Ok, no more github comments from me at 0200.

[st-pasha]

My gut feeling is that the Flame FPS is the more important one: if I can only redraw and update the canvas 10 times a second, then it doesn't matter that the Flame goes at 100 fps -- there won't be any visible difference during those extra frames. But maybe my gut feeling is wrong, so I'd be really interested in hearing how to reason about this.

I guess one thing that's outside the main game loop is the events system. So maybe if I can track finger movement or key presses at 100 fps, even though I can only update the game state at 10fps, maybe that makes all the difference?

[spydon]

In the updated version of the PR there is not much difference between what the devtools report and what our fps tracker reports I think, it was just bad math in the previous implementation.

[st-pasha]

The discussion here is not about whether we can match the number reported in the devtools, but rather whether we should be trying to match it. Which fps measure is more relevant.

[spydon]

The discussion was sparked from that the FPS measurements differed (as you can read on the initial post), that is no longer the case, so what I'm trying to say is that the discussion is not really relevant anymore. I think that the FPS reported by the devtools is capped with how fast we can render in flame, it is single threaded after all. I don't think they measure anything from the event loop in their fps measurements, why would they?