OS.low_processor_usage_mode in Android makes problems to Anim, Tween, and CheckButton nodes

[tam0705]

Godot version:
Godot 3.0.2 stable

OS/device including version:
Windows 10 Pro
Exporting to Android 6.0, Samsung Galaxy J2 Prime

Issue description:
When being played in the project, OS.low_processor_usage_mode made my animations not smooth, which is very normal for me. But when being exported and run in Android, it made weird and actually funny problems to my animations, tweens, and checkbuttons. Every scene of mine has its own anims and tweens, where some scenes only had their anims affected and the others had their tweens affected. The settings scene is the only one who has CheckButtons and those nodes were also affected. It is really hard to explain the problem so I just provide a video: https://youtu.be/nSS_nzAhR6g

Notice in the video that I tested the game before enabling low usage mode, then something weird happened after I turned it on. (It is when I enabled power saving)

Note: I used Tweens only for moving the cards and the buttons in the bottom of the screen. Other motions besides them are made using AnimationPlayers

[romeojulietthotel]

You may follow these threads, if you haven't already. Maybe they help?

• Target FPS option removed - how to handle low FPS for battery saving on mobile? #6727
• OS.set_low_processor_usage_mode not working and creating problems on Android #7980

Did you test without OS.low_processor_usage_mode to make sure?

[bojidar-bg]

Just to confirm, it happens only on android, right? (also, might be nice to mention the device tested)

From what I can see on the video, what happens is that the after the animation is over, the last two frames start swapping in quick succession, presumably because someone continues swapping the buffers, even if nothing is rerendered.

[tam0705]

@romeojulietthotel I've tested it in the Android itself both with OS.low_processor_usage_mode and without it. You can see it on the video. About the issues you linked, I don't think they helped, seeing I myself don't actually understand the #6727 one. XD
@bojidar-bg Yes, it only happened in my android. The device is Samsung Galaxy J2 Prime. I think I have to test in my family's devices too, since those devices have the different versions of Android.

[reduz]

I dont think this feature was ever properly implemented on Android

[tam0705]

Well, I failed to test it in my other's family devices because of many outside.. issues.
Lmao XD @reduz If that's so I think I have to disable power saving feature in my game for a while :v

[zhagsenkk]

link: https://gamejolt.com/games/mult/360731 (only html platform , pic 1 and 2 recording frequency are 20fps , pic 3 is 60fps)

Win10 64，Chrome 68.0.3440.106（32 bit）

I dont know if these are related.

[tavurth]

Just a note that this issue has now been present for almost 5 years, spreading across several different issues, notably:

#6727
#7980
#30417

As a newer Godot developer I ran across this the first time when one of my GUI apps was blocked from the play store as it was unresponsive due to this infamous "OS.low_processor_usage" flicker.

Perhaps if this issue will not be fixed until Godot 4.0, it would be better to automatically disable this when exporting to Android devices.

The feature description is alluring, and yet causes problems for new developers and inhibits adoption.

As a workaround I currently use:

OS.low_processor_usage_mode = OS.get_name() != "Android"

New developers to Godot should not be expected to find this thread, as the system should work as close as possible to the dev docs however.

[Gromph]

I found a simple solution to this problem, which is to force draw 2 more frames after the last changed frame. Here is my fix for 3.x:
SilverCreekEntertainment@30d337c

It is important for our games, because there can be periods of time when the user is looking at their hand in a card game deciding their next move with no drawing going on.

I don't know if this is still an issue on master, but the code in main.cpp looks the same and the same fix could be applied to master.

Let me know if this fix looks good and I can make it a pull request.

[Gromph]

Oops, the flicker returns if you task switch to another app and back. So probably need to force draw a few more frames when re-gaining focus.

[Gromph]

Ok, I think I got all the flickers fixed, the fix was to force redraw 3 frames after GodotRenderer::onSurfaceChanged gets called.
Here is my new fix for 3.x: SilverCreekEntertainment@94364e3

I reworked Main::force_redraw to take number of frames to redraw and have Main::iteration redraw that many in a row. I'm not sure if this is the best solution or not, it's working pretty good for our games though. But could use lots more testing. I set it to redraw 3 frames by trial and error.
To test thoroughly you need to try things that cause the gl surface to be lost, like switch apps, turn screen off and on, rotate phone, etc.

[Calinou]

Ok, I think I got all the flickers fixed, the fix was to force redraw 3 frames after GodotRenderer::onSurfaceChanged gets called.
Here is my new fix for 3.x: SilverCreekEntertainment@94364e3

Feel free to open a pull request for this 🙂

Note that we'll need a master version of the pull request for the 3.x version to be merged, but the 3.x version should still be opened since the master PR will use different, incompatible code.

[fahrstuhl]

Any idea what the source of the problem could be? If the magic number seems to be 2 or 3, is this solution filling the buffers of VSync or triple buffering that otherwise contain older frames?

[tavurth]

My idea: Maybe when the app reloads it creates a lag frame from the foreground activities, then loading the last rendered frame which was done at app exit (black).

This seems a bit weird though because the app is often flickering rather than some black screen, and there is also some frozen logic from what I've seen (splash screen not progressing to full app).

Perhaps somehow the back-side of the buffer ends up out of sync and it just renders over and over again when flipping? (Idea being that the app is rendering always OK on one buffer but the back-side is intermittent.)

Just jamming ideas 😄

[Gromph]

Any idea what the source of the problem could be? If the magic number seems to be 2 or 3, is this solution filling the buffers of VSync or triple buffering that otherwise contain older frames?

That would be my assumption, but I'm not a gpu expert.

My idea: Maybe when the app reloads it creates a lag frame from the foreground activities, then loading the last rendered frame which was done at app exit (black).

The App isn't reloading, it's just losing and recreating the open gl surface. I don't know if there would be some way to render one frame and fill all buffers.

I'm testing version v4.0.dev.20211117.official [175690957]. And have not reproduced the flicker when it stops rendering, but the screen does go black if surface is lost due to app switching and screen off/on. Rotating phone is working ok though.