Closed RblSb closed 2 years ago
Let's sneakily detect the refresh-rate while the application is running instead.
The display frequency is used in one place, by Scheduler for managing timetasks. If the frequency is significantly lower than the actual device refresh rate you get stuttering or incompletion of the timetasks at the appropriate time, or something like that. So it does need to be set right.
You are right, there is side effect based on get_frequency
:
https://github.com/Kode/Kha/blob/87cdf3f2523a713bdce2869915c44fa03d99653c/Sources/kha/Scheduler.hx#L94
If we change this var to inline property, that will always request actual refresh rate, this would be ok?
So we will get 60 fps on first app seconds (not so laggy for loading screen/etc), and then it will speedup to calculated hz. This inline property should also be handled only for html5 target, without native targets overhead.
Yes, that approach would be ok - best we can do.
If you remove this block: https://github.com/Kode/Kha/blob/1b0dc6a494277987c2ed5c8c568aac412e34eb93/Backends/HTML5/kha/SystemImpl.hx#L545-L640 Initialization will be instant.
Since this feature is only implemented for
Display.get_frequency
value and not used in Kha logic, i suggest to replace it with:And handle absence of this feature in html5 target with documentation. Or, if you guys think this is vital for Kha-based code, lets introduce some define for accurate frequency, but i think many people would like to get instant init.