filip
December 4, 2024, 2:43pm
1
Hey, just thought I’d share this here. I just filed these two issues, mostly with an eye for game development. I wonder if there are app developers who could use framerate and/or DPI limiting, too.
opened 02:14PM - 04 Dec 24 UTC
### Use case
In games, it is common to limit the resolution of the output as a … tradeoff between quality and performance. Games need to run smooth even when the user has a 5K screen, so they simply render to a lower-than-native resolution.
I think this might get more and more relevant to Flutter because of the following trends:
1. Steadily increasing resolutions of screens[^1]
3. Higher and higher table-stakes for complexity of UI (e.g. todays UIs have a lot more frosted glass and always-on animations than 5 or 10 years ago)
4. Gaming itself being a promising target for Flutter (where screens are generally even more complex than in apps)
5. Flutter now targeting desktop (incl. desktop web) where a screen can easily have 8-14 megapixels
6. Moore's law slowing down[^2] or even reaching its limits (especially through memory wall)
[^1]: https://gs.statcounter.com/screen-resolution-stats/mobile/worldwide/#monthly-200903-202412
[^2]: https://www.zdnet.com/article/as-moores-law-slows-high-end-applications-may-feel-the-effect-mit-scientist-warns/
### Proposal
It would be great to have the option of switching the app (or game) to a specified resolution or limiting its DPI. A common gaming approach is to only allow this after restart (i.e. user changes resolution --> game asks to be restarted for changes to take effect). This is not ideal but better than nothing.
This is one of the things that should be _possible_ but don't need to be _easy_. The vast majority of Flutter developers won't need this. So, for example, I can imagine the embedder selecting a resolution from an environment variable and, if not present, doing its usual thing (i.e. using the highest possible DPI).
opened 02:27PM - 04 Dec 24 UTC
### Use case
I have noticed that Unity automatically limits games to 30 FPS on … mobile devices.[^5] The developer can override this but it's a pretty well-hidden setting and I think most don't.
This is a trade off I can completely understand since 30 FPS is probably more than enough for most mobile games, and it saves battery and reduces jank (it’s much harder to miss a 33ms frame than it is to miss a 16ms frame).
There is no such possibility in Flutter. Flutter tries to render at the native framerate. (Not sure what the story with 120Hz screens is, to be honest, but I'd expect Flutter to try to match the refresh rate of the screen.)
This problem is related to https://github.com/flutter/flutter/issues/159796 (which deals with limiting resolution/DPI rather than framerate). To pull a relevant quote from that issue:
> I think this might get more and more relevant to Flutter because of the following trends:
>
> 1. Steadily increasing resolutions of screens[^1]
> 3. Higher and higher table-stakes for complexity of UI (e.g. todays UIs have a lot more frosted glass and always-on animations than 5 or 10 years ago)
> 4. Gaming itself being a promising target for Flutter (where screens are generally even more complex than in apps)
> 5. Flutter now targeting desktop (incl. desktop web) where a screen can easily have 8-14 megapixels
> 6. Moore's law slowing down[^2] or even reaching its limits (especially through memory wall)
[^1]: https://gs.statcounter.com/screen-resolution-stats/mobile/worldwide/#monthly-200903-202412
[^2]: https://www.zdnet.com/article/as-moores-law-slows-high-end-applications-may-feel-the-effect-mit-scientist-warns/
[^5]: https://filiph.net/text/benchmarking-flutter-flame-unity-godot.html
### Proposal
To enable more complex apps, and _especially_ games, to render without jank, I suggest there's a way to tell the embedder to render at a framerate lower than the native one.
I realize this seems like a crutch and in a perfect world there would be no need for such a setting but again, Unity (currently the most successful game engine for mobile) is doing 30 FPS _by default_.
// cc @bdero
1 Like