Repository navigation
backgroundFPS in 2.0.0? #246
Description
I noticed recently that when my game window is in the background, the CPU usage spikes to ~80% for some reason. I was able to fix this by setting the backgroundFPS option explicitly (I chose 10 because my game isn't very graphics intensive anyway) in the current stable version, but as part of my investigation into this issue I also tried porting to 2.0.0-alpha26 and discovered that this option does not exist—and the CPU spike issue is still there.
Is there a migration path for backgroundFPS?
I'm on macOS 10.15.4.
Unrelated, but other things I noticed in that experiment with 2.0.0:
- The
Colorsclass introduced in 2.0.0 produces different colors from the same-named constants in libgdx, but I assume that's on purpose. - The window in the lwjgl3 seems more heavyweight somehow. On 1.9.10 I can smoothly move the window around with my mouse, but in 2.0.0 the same gesture is very sluggish.
Thanks :)
Activity
tomcashman commentedon May 21, 2020
It looks like LibGDX's LWJGL3 implementation doesn't have the backgroundFPS config option anymore so we'll them to support it first. You could use the LWJGL2 desktop runtime if you wish to still use it but LWJGL2 is no longer maintained.
For the Colors, can you let me know which ones are different? Some may have changed to match their HTML5 definitions or there may be an actual bug there.
1.9.10 was using LibGDX's LWJGL2 backend only. We're using LibGDX's LWJGL3 implementation so I'm unsure if the sluggish-ness is due to their implementation or an actual LWJGL3/GLFW issue.
dhleong commentedon May 21, 2020
Wow, thanks for the rapid response!
Aha, good to know. I may play with that later today to see whether it's LWJGL3 in particular causing the sluggishness issue, as well.
PURPLE off the top of my head. Matching HTML5 makes sense! I can always manually define colors so this is not a huge deal, just thought I'd mention it in case it was unintentional.
Sorry for bringing up another aside, but I noticed that lwjgl3 requires the -XstartOnFirstThread JVM flag, while having that on lwjgl2/mini 1.9.10 will actually cause the window to never open. Do you have any tips for working around that, or is it just an implementation of lwjgl3 that has to be dealt with?
dhleong commentedon May 22, 2020
Just tried using the lwjgl2 backend on 2.0.0 and the performance seems to be approximately the same as with 1.9.10, so it's probably the lwjgl3 backend at fault.
Any other differences between 1.9 and 2.0 we should be aware of? I haven't seen any migration docs or anything.
tomcashman commentedon May 22, 2020
There'll be official migration docs revealed once 2.0 beta is launched (hopefully in June, extremely busy with some deadlines atm).
The main migration is to avoid using the libgdx imports and use the mini2Dx equivalents instead. This will ensure that your game can cross-compile to consoles and other future platforms.