Kode / Kha

Ultra-portable, high performance, open source multimedia framework.
http://kha.tech
zlib License
1.48k stars 174 forks source link

[html5] Refresh rate detection delays System.start for 2 seconds #1388

Closed RblSb closed 2 years ago

RblSb commented 2 years ago

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:

requestAnimationFrame(animate);
callback(SystemImpl.window);

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.

RobDangerous commented 2 years ago

Let's sneakily detect the refresh-rate while the application is running instead.

zshoals commented 2 years ago

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.

RblSb commented 2 years ago

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.

RobDangerous commented 2 years ago

Yes, that approach would be ok - best we can do.