Godot: Target FPS option removed - how to handle low FPS for battery saving on mobile?

[florix91]

Operating system or device - Godot version:

Issue description (what happened, and what was expected):

Steps to reproduce:

Link to minimal example project (optional but very welcome):

[reduz]

yeah, we removed this because it was misleading, you can change the phyics
FPS if you want, but the game FPS will be always fixed to your refresh rate.

On Thu, Oct 6, 2016 at 12:30 PM, florix91 [email protected] wrote:

_Operating system or device - Godot version:_

_Issue description_ (what happened, and what was expected):

_Steps to reproduce:_

_Link to minimal example project_ (optional but very welcome):

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z24oIhHfTvh6Q6pb1ekdwunvptaUvks5qxRP7gaJpZM4KQFUz
.

[florix91]

Sorry so how can i set to 15 fps my application for example?

2016-10-06 17:40 GMT+02:00 Juan Linietsky [email protected]:

yeah, we removed this because it was misleading, you can change the phyics
FPS if you want, but the game FPS will be always fixed to your refresh
rate.

On Thu, Oct 6, 2016 at 12:30 PM, florix91 [email protected]
wrote:

_Operating system or device - Godot version:_

_Issue description_ (what happened, and what was expected):

_Steps to reproduce:_

_Link to minimal example project_ (optional but very welcome):

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727, or mute the thread
Z24oIhHfTvh6Q6pb1ekdwunvptaUvks5qxRP7gaJpZM4KQFUz>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252001624,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANZmYtUiDML5DwZZHAGVjK-rtg8HttJrks5qxRZlgaJpZM4KQFUz
.

[reduz]

there is not much of a point in doing this, so this is unsupported

On Thu, Oct 6, 2016 at 12:46 PM, florix91 [email protected] wrote:

Sorry so how can i set to 15 fps my application for example?

2016-10-06 17:40 GMT+02:00 Juan Linietsky [email protected]:

yeah, we removed this because it was misleading, you can change the
phyics
FPS if you want, but the game FPS will be always fixed to your refresh
rate.

On Thu, Oct 6, 2016 at 12:30 PM, florix91 [email protected]
wrote:

_Operating system or device - Godot version:_

_Issue description_ (what happened, and what was expected):

_Steps to reproduce:_

_Link to minimal example project_ (optional but very welcome):

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727, or mute the thread
Z24oIhHfTvh6Q6pb1ekdwunvptaUvks5qxRP7gaJpZM4KQFUz>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/godotengine/godot/issues/6727#issuecomment-252001624
,
or mute the thread
auth/ANZmYtUiDML5DwZZHAGVjK-rtg8HttJrks5qxRZlgaJpZM4KQFUz>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252003513,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z249EbsJKOmaej274k2Aky2G8Cw3Iks5qxRfKgaJpZM4KQFUz
.

[reduz]

you could set the physics fps to 15 and do all your logic in
fixed_process.. but you are most likely doing something wrong

On Thu, Oct 6, 2016 at 12:47 PM, Juan Linietsky [email protected] wrote:

there is not much of a point in doing this, so this is unsupported

On Thu, Oct 6, 2016 at 12:46 PM, florix91 [email protected]
wrote:

Sorry so how can i set to 15 fps my application for example?

2016-10-06 17:40 GMT+02:00 Juan Linietsky [email protected]:

yeah, we removed this because it was misleading, you can change the
phyics
FPS if you want, but the game FPS will be always fixed to your refresh
rate.

On Thu, Oct 6, 2016 at 12:30 PM, florix91 [email protected]
wrote:

_Operating system or device - Godot version:_

_Issue description_ (what happened, and what was expected):

_Steps to reproduce:_

_Link to minimal example project_ (optional but very welcome):

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727, or mute the
thread
Z24oIhHfTvh6Q6pb1ekdwunvptaUvks5qxRP7gaJpZM4KQFUz>
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
nt-252001624>,
or mute the thread
ANZmYtUiDML5DwZZHAGVjK-rtg8HttJrks5qxRZlgaJpZM4KQFUz>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252003513,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z249EbsJKOmaej274k2Aky2G8Cw3Iks5qxRfKgaJpZM4KQFUz
.

[freemanfromgodotengine]

@reduz I was using that trick - lowering from 60 to 30 fps - to lower battery consumption on android devices and as far as I was able to test, it worked, so not entirely 'not much of a point', at least for me.

[florix91]

​@reduz yes i was using that trick too for lowering battery consumption on
android devices, and using OS.set_low_processor_usage_mode(true) . And for
me was working great....To not make just game but even little app that will
not consume battery like a game....
however it was under the func _ready():
why cannot i use that?​

2016-10-06 21:26 GMT+02:00 Freeman [email protected]:

@reduz https://github.com/reduz I was using that trick - lowering from
60 to 30 fps - to lower battery consumption on android devices and as far
as I was able to test, it worked, so not entirely 'not much of a point', at
least for me.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252063683,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANZmYq1_Qqc_iwmus8RidSvHrENoFC90ks5qxUtlgaJpZM4KQFUz
.

[CowThing]

What should I do if I want to have vsync off but not have the game run at several hundred FPS? Many games offer an option to set the FPS cap and set the vsync separately.

[reduz]

OS.set_low_processor_usage_mode(bool) is not working currently on Android, it should really be implemented as it' s a great way of saving battery if you are using Godot to make apps and not games.

@RandomShaper would you like to give this a try? basically it means skipping OpenGL redraw of next frame (and keep the current one) if VisualServer::get_singleton()->has_changed() returns false

[florix91]

@reduz hope you make OS.set_low_processor_usage_mode(bool) working for
Android and iOS as soon as possible. Thanks

On Oct 6, 2016 21:55, "Juan Linietsky" [email protected] wrote:

OS.set_low_processor_usage_mode(bool) is not working currently on
Android, it should really be implemented as it' s a great way of saving
battery if you are using Godot to make apps and not games.

@RandomShaper https://github.com/RandomShaper would you like to give
this a try? basically it means skipping OpenGL redraw of next frame (and
keep the current one) if VisualServer::get_singleton()->has_changed()
returns false

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252070671,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANZmYvAZjQpArA08LZtZcOcaAgcTJUkbks5qxVIfgaJpZM4KQFUz
.

[RandomShaper]

I'm researching it.

[RandomShaper]

I've found that the check for low CPU usage mode is perfomed at every iteration of the main loop (main/main.cpp). Because of that it should already work on every platform.

For instance, on the Android case the callback to re-render the GL surface calls through that code so it should already skip frames and add delays.

Any thoughts on this?

[florix91]

On Android this line of code cause a flashing Like mode of the scene Where
it is used
​ OS.set_low_processor_usage_mode(true) at least for me. And juan told us
that is not working on Android at the moment but will be implemented..(i
really hope soon to make apps and not only games).
​

On Oct 8, 2016 20:01, "Pedro J. Estébanez" [email protected] wrote:

I've found that the check for low CPU usage mode is perfomed at every
iteration of the main loop (_main/main.cpp_). Because of that it should
already work on every platform.

For instance, on the Android case the callback to re-render the GL surface
calls through that code so it should already skip frames and add delays.

Any thoughts on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252439099,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANZmYis6qp4sky-P1Rw2rGEBCm8wt6q2ks5qx9qIgaJpZM4KQFUz
.

[reduz]

Yes, you are already at the OpenGL frame when this callback happens, and
Android controls the swapping of buffers.
The only way this could be implemented in Android is to somehow avoid the
buffer swapping of the current frame.
Still, in GodotView.java, all you get is a callback to draw and Android
seems to swap buffers internally.

On Sat, Oct 8, 2016 at 3:31 PM, florix91 [email protected] wrote:

On Android this line of code cause a flashing Like mode of the scene Where
it is used
​ OS.set_low_processor_usage_mode(true) at least for me. And juan told us
that is not working on Android at the moment but will be implemented..(i
really hope soon to make apps and not only games).
​

On Oct 8, 2016 20:01, "Pedro J. Estébanez" [email protected]
wrote:

I've found that the check for low CPU usage mode is perfomed at every
iteration of the main loop (_main/main.cpp_). Because of that it should
already work on every platform.

For instance, on the Android case the callback to re-render the GL
surface
calls through that code so it should already skip frames and add delays.

Any thoughts on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/godotengine/godot/issues/6727#issuecomment-252439099
,
or mute the thread
P1Rw2rGEBCm8wt6q2ks5qx9qIgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252440546,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2wBtV7aq3oHTR3UdXaXGQP2Bxqqdks5qx-GHgaJpZM4KQFUz
.

[reduz]

All I found is this:
https://developer.android.com/reference/android/opengl/GLSurfaceView.html#requestRender()
which could obviously work, but then who calls the frame callbacks? Also
you would have some delay between processing and drawing.

On Sat, Oct 8, 2016 at 4:14 PM, Juan Linietsky [email protected] wrote:

Yes, you are already at the OpenGL frame when this callback happens, and
Android controls the swapping of buffers.
The only way this could be implemented in Android is to somehow avoid the
buffer swapping of the current frame.
Still, in GodotView.java, all you get is a callback to draw and Android
seems to swap buffers internally.

On Sat, Oct 8, 2016 at 3:31 PM, florix91 [email protected] wrote:

On Android this line of code cause a flashing Like mode of the scene Where
it is used
​ OS.set_low_processor_usage_mode(true) at least for me. And juan told us
that is not working on Android at the moment but will be implemented..(i
really hope soon to make apps and not only games).
​

On Oct 8, 2016 20:01, "Pedro J. Estébanez" [email protected]
wrote:

I've found that the check for low CPU usage mode is perfomed at every
iteration of the main loop (_main/main.cpp_). Because of that it should
already work on every platform.

For instance, on the Android case the callback to re-render the GL
surface
calls through that code so it should already skip frames and add delays.

Any thoughts on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
nt-252439099>,
or mute the thread
ANZmYis6qp4sky-P1Rw2rGEBCm8wt6q2ks5qx9qIgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252440546,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2wBtV7aq3oHTR3UdXaXGQP2Bxqqdks5qx-GHgaJpZM4KQFUz
.

[RandomShaper]

Yeah, setRenderMode()/requestRender() seem to be the way to go. I'm
looking into them…

El 08/10/2016 a las 21:22, Juan Linietsky escribió:

All I found is this:
https://developer.android.com/reference/android/opengl/GLSurfaceView.html#requestRender()
which could obviously work, but then who calls the frame callbacks? Also
you would have some delay between processing and drawing.

On Sat, Oct 8, 2016 at 4:14 PM, Juan Linietsky [email protected] wrote:

Yes, you are already at the OpenGL frame when this callback happens, and
Android controls the swapping of buffers.
The only way this could be implemented in Android is to somehow
avoid the
buffer swapping of the current frame.
Still, in GodotView.java, all you get is a callback to draw and Android
seems to swap buffers internally.

On Sat, Oct 8, 2016 at 3:31 PM, florix91 [email protected]
wrote:

On Android this line of code cause a flashing Like mode of the
scene Where
it is used
​ OS.set_low_processor_usage_mode(true) at least for me. And juan
told us
that is not working on Android at the moment but will be
implemented..(i
really hope soon to make apps and not only games).
​

On Oct 8, 2016 20:01, "Pedro J. Estébanez" [email protected]
wrote:

I've found that the check for low CPU usage mode is perfomed at every
iteration of the main loop (_main/main.cpp_). Because of that it
should
already work on every platform.

For instance, on the Android case the callback to re-render the GL
surface
calls through that code so it should already skip frames and add
delays.

Any thoughts on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
nt-252439099>,
or mute the thread
ANZmYis6qp4sky-P1Rw2rGEBCm8wt6q2ks5qx9qIgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/godotengine/godot/issues/6727#issuecomment-252440546,
or mute the thread

https://github.com/notifications/unsubscribe-auth/AF-Z2wBtV7aq3oHTR3UdXaXGQP2Bxqqdks5qx-GHgaJpZM4KQFUz
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252443177,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCtlwpM_tynrImh2XPiTfKErIEFXIkks5qx-10gaJpZM4KQFUz.

[reduz]

the problem is the delay.. Godot can render in a thread in the worst case,
but I'm wondering if this is not kinda too much

On Sat, Oct 8, 2016 at 4:25 PM, Pedro J. Estébanez <[email protected]

wrote:

Yeah, setRenderMode()/requestRender() seem to be the way to go. I'm
looking into them…

El 08/10/2016 a las 21:22, Juan Linietsky escribió:

All I found is this:
https://developer.android.com/reference/android/opengl/
GLSurfaceView.html#requestRender()
which could obviously work, but then who calls the frame callbacks? Also
you would have some delay between processing and drawing.

On Sat, Oct 8, 2016 at 4:14 PM, Juan Linietsky [email protected]
wrote:

Yes, you are already at the OpenGL frame when this callback happens,
and
Android controls the swapping of buffers.
The only way this could be implemented in Android is to somehow
avoid the
buffer swapping of the current frame.
Still, in GodotView.java, all you get is a callback to draw and Android
seems to swap buffers internally.

On Sat, Oct 8, 2016 at 3:31 PM, florix91 [email protected]
wrote:

On Android this line of code cause a flashing Like mode of the
scene Where
it is used
​ OS.set_low_processor_usage_mode(true) at least for me. And juan
told us
that is not working on Android at the moment but will be
implemented..(i
really hope soon to make apps and not only games).
​

On Oct 8, 2016 20:01, "Pedro J. Estébanez" [email protected]
wrote:

I've found that the check for low CPU usage mode is perfomed at
every
iteration of the main loop (_main/main.cpp_). Because of that it
should
already work on every platform.

For instance, on the Android case the callback to re-render the GL
surface
calls through that code so it should already skip frames and add
delays.

Any thoughts on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
nt-252439099>,
or mute the thread
ANZmYis6qp4sky-P1Rw2rGEBCm8wt6q2ks5qx9qIgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/godotengine/godot/issues/6727#issuecomment-252440546
,
or mute the thread

Z2wBtV7aq3oHTR3UdXaXGQP2Bxqqdks5qx-GHgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252443177,

or mute the thread
tynrImh2XPiTfKErIEFXIkks5qx-10gaJpZM4KQFUz>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252443332,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z28NFcCs2fre7e0UvhEIMDoCXE7NUks5qx-4VgaJpZM4KQFUz
.

[RandomShaper]

Not sure if that's what you mean, but GLSurfaceView already employs a
thread for the frame callbacks. Is blocking the main thread your concern
here?

El 08/10/2016 a las 21:38, Juan Linietsky escribió:

the problem is the delay.. Godot can render in a thread in the worst case,
but I'm wondering if this is not kinda too much

On Sat, Oct 8, 2016 at 4:25 PM, Pedro J. Estébanez
<[email protected]

wrote:

Yeah, setRenderMode()/requestRender() seem to be the way to go. I'm
looking into them…

El 08/10/2016 a las 21:22, Juan Linietsky escribió:

All I found is this:
https://developer.android.com/reference/android/opengl/
GLSurfaceView.html#requestRender()
which could obviously work, but then who calls the frame
callbacks? Also
you would have some delay between processing and drawing.

On Sat, Oct 8, 2016 at 4:14 PM, Juan Linietsky [email protected]
wrote:

Yes, you are already at the OpenGL frame when this callback happens,
and
Android controls the swapping of buffers.
The only way this could be implemented in Android is to somehow
avoid the
buffer swapping of the current frame.
Still, in GodotView.java, all you get is a callback to draw and
Android
seems to swap buffers internally.

On Sat, Oct 8, 2016 at 3:31 PM, florix91 [email protected]
wrote:

On Android this line of code cause a flashing Like mode of the
scene Where
it is used
​ OS.set_low_processor_usage_mode(true) at least for me. And juan
told us
that is not working on Android at the moment but will be
implemented..(i
really hope soon to make apps and not only games).
​

On Oct 8, 2016 20:01, "Pedro J. Estébanez"
[email protected]
wrote:

I've found that the check for low CPU usage mode is perfomed at
every
iteration of the main loop (_main/main.cpp_). Because of that it
should
already work on every platform.

For instance, on the Android case the callback to re-render
the GL
surface
calls through that code so it should already skip frames and add
delays.

Any thoughts on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
nt-252439099>,
or mute the thread
ANZmYis6qp4sky-P1Rw2rGEBCm8wt6q2ks5qx9qIgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/godotengine/godot/issues/6727#issuecomment-252440546
,

or mute the thread

Z2wBtV7aq3oHTR3UdXaXGQP2Bxqqdks5qx-GHgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/godotengine/godot/issues/6727#issuecomment-252443177,

or mute the thread
tynrImh2XPiTfKErIEFXIkks5qx-10gaJpZM4KQFUz>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/godotengine/godot/issues/6727#issuecomment-252443332,
or mute the thread

https://github.com/notifications/unsubscribe-auth/AF-Z28NFcCs2fre7e0UvhEIMDoCXE7NUks5qx-4VgaJpZM4KQFUz
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252444031,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCtpaoxY7TEPcl_fqxHZP37mmV9Bvpks5qx_EngaJpZM4KQFUz.

[reduz]

Godot supports rendering in a thread, so technically it could be possible
(probably with a little work also from the engine side), to run Godot on
the main thread and do rendering in another. This was, however, never done.
If there is no other way to get the low cpu mode to work, I will make sure
threaded rendering works on Android (which is quite some work).

The easy solution would be to simply be able to abort the current frame
being drawn (do not swapbuffers or blit), is this not possible in any way?
Who does perform the swap in GLSurfaceView?

On Sat, Oct 8, 2016 at 4:45 PM, Pedro J. Estébanez <[email protected]

wrote:

Not sure if that's what you mean, but GLSurfaceView already employs a
thread for the frame callbacks. Is blocking the main thread your concern
here?

El 08/10/2016 a las 21:38, Juan Linietsky escribió:

the problem is the delay.. Godot can render in a thread in the worst
case,
but I'm wondering if this is not kinda too much

On Sat, Oct 8, 2016 at 4:25 PM, Pedro J. Estébanez
<[email protected]

wrote:

Yeah, setRenderMode()/requestRender() seem to be the way to go. I'm
looking into them…

El 08/10/2016 a las 21:22, Juan Linietsky escribió:

All I found is this:
https://developer.android.com/reference/android/opengl/
GLSurfaceView.html#requestRender()
which could obviously work, but then who calls the frame
callbacks? Also
you would have some delay between processing and drawing.

On Sat, Oct 8, 2016 at 4:14 PM, Juan Linietsky [email protected]
wrote:

Yes, you are already at the OpenGL frame when this callback
happens,
and
Android controls the swapping of buffers.
The only way this could be implemented in Android is to somehow
avoid the
buffer swapping of the current frame.
Still, in GodotView.java, all you get is a callback to draw and
Android
seems to swap buffers internally.

On Sat, Oct 8, 2016 at 3:31 PM, florix91 <[email protected]

wrote:

On Android this line of code cause a flashing Like mode of the
scene Where
it is used
​ OS.set_low_processor_usage_mode(true) at least for me. And juan
told us
that is not working on Android at the moment but will be
implemented..(i
really hope soon to make apps and not only games).
​

On Oct 8, 2016 20:01, "Pedro J. Estébanez"
[email protected]
wrote:

I've found that the check for low CPU usage mode is perfomed at
every
iteration of the main loop (_main/main.cpp_). Because of that it
should
already work on every platform.

For instance, on the Android case the callback to re-render
the GL
surface
calls through that code so it should already skip frames and add
delays.

Any thoughts on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
nt-252439099>,
or mute the thread
ANZmYis6qp4sky-P1Rw2rGEBCm8wt6q2ks5qx9qIgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/godotengine/godot/issues/6727#issuecomment-252440546
,

or mute the thread

Z2wBtV7aq3oHTR3UdXaXGQP2Bxqqdks5qx-GHgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/godotengine/godot/issues/6727#issuecomment-252443177
,

or mute the thread
tynrImh2XPiTfKErIEFXIkks5qx-10gaJpZM4KQFUz>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/godotengine/godot/issues/6727#issuecomment-252443332
,
or mute the thread

Z28NFcCs2fre7e0UvhEIMDoCXE7NUks5qx-4VgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252444031,

or mute the thread
fqxHZP37mmV9Bvpks5qx_EngaJpZM4KQFUz>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252444402,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2-WETR6RcRxIu9ayIhK6sFt9sPKjks5qx_LhgaJpZM4KQFUz
.

[RandomShaper]

I think there are two possible workarounds:

• Since a helper class in GLSurfaceView is the one that performs the
  swap, we could grab a copy of the original from the Android source
  code and modify it to conditionally swap according to our needs.
  Downside: a little bit of maintenance.
• Another one I'm going to try right now and detail (and PR) if success.

El 08/10/2016 a las 23:12, Juan Linietsky escribió:

Godot supports rendering in a thread, so technically it could be possible
(probably with a little work also from the engine side), to run Godot on
the main thread and do rendering in another. This was, however, never
done.
If there is no other way to get the low cpu mode to work, I will make sure
threaded rendering works on Android (which is quite some work).

The easy solution would be to simply be able to abort the current frame
being drawn (do not swapbuffers or blit), is this not possible in any way?
Who does perform the swap in GLSurfaceView?

On Sat, Oct 8, 2016 at 4:45 PM, Pedro J. Estébanez
<[email protected]

wrote:

Not sure if that's what you mean, but GLSurfaceView already employs a
thread for the frame callbacks. Is blocking the main thread your concern
here?

El 08/10/2016 a las 21:38, Juan Linietsky escribió:

the problem is the delay.. Godot can render in a thread in the worst
case,
but I'm wondering if this is not kinda too much

On Sat, Oct 8, 2016 at 4:25 PM, Pedro J. Estébanez
<[email protected]

wrote:

Yeah, setRenderMode()/requestRender() seem to be the way to go. I'm
looking into them…

El 08/10/2016 a las 21:22, Juan Linietsky escribió:

All I found is this:
https://developer.android.com/reference/android/opengl/
GLSurfaceView.html#requestRender()
which could obviously work, but then who calls the frame
callbacks? Also
you would have some delay between processing and drawing.

On Sat, Oct 8, 2016 at 4:14 PM, Juan Linietsky [email protected]
wrote:

Yes, you are already at the OpenGL frame when this callback
happens,
and
Android controls the swapping of buffers.
The only way this could be implemented in Android is to somehow
avoid the
buffer swapping of the current frame.
Still, in GodotView.java, all you get is a callback to draw and
Android
seems to swap buffers internally.

On Sat, Oct 8, 2016 at 3:31 PM, florix91
<[email protected]

wrote:

On Android this line of code cause a flashing Like mode of the
scene Where
it is used
​ OS.set_low_processor_usage_mode(true) at least for me.
And juan
told us
that is not working on Android at the moment but will be
implemented..(i
really hope soon to make apps and not only games).
​

On Oct 8, 2016 20:01, "Pedro J. Estébanez"
[email protected]
wrote:

I've found that the check for low CPU usage mode is
perfomed at
every
iteration of the main loop (_main/main.cpp_). Because of
that it
should
already work on every platform.

For instance, on the Android case the callback to re-render
the GL
surface
calls through that code so it should already skip frames
and add
delays.

Any thoughts on this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
nt-252439099>,
or mute the thread
ANZmYis6qp4sky-P1Rw2rGEBCm8wt6q2ks5qx9qIgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/godotengine/godot/issues/6727#issuecomment-252440546

,

or mute the thread

Z2wBtV7aq3oHTR3UdXaXGQP2Bxqqdks5qx-GHgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/godotengine/godot/issues/6727#issuecomment-252443177
,

or mute the thread
tynrImh2XPiTfKErIEFXIkks5qx-10gaJpZM4KQFUz>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

<https://github.com/godotengine/godot/issues/6727#issuecomment-252443332
,

or mute the thread

Z28NFcCs2fre7e0UvhEIMDoCXE7NUks5qx-4VgaJpZM4KQFUz>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/godotengine/godot/issues/6727#issuecomment-252444031,

or mute the thread
fqxHZP37mmV9Bvpks5qx_EngaJpZM4KQFUz>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub

https://github.com/godotengine/godot/issues/6727#issuecomment-252444402,
or mute the thread

https://github.com/notifications/unsubscribe-auth/AF-Z2-WETR6RcRxIu9ayIhK6sFt9sPKjks5qx_LhgaJpZM4KQFUz
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-252448679,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQCti9_B81molIasqHmEQbffqpThBqEks5qyAcpgaJpZM4KQFUz.

[RandomShaper]

My little experiment failed, so here are my options:

1. Grab GLSurfaceView from the Android SDK corresponding to the minSdkVersion (currently, 14). It employs some private APIs and, although they probably could be stripped out, maintining a patched copy of it is ugly.
2. Play with EGL_SWAP_BEHAVIOR set to EGL_BUFFER_PRESERVED. That would make almost irrelevant that GLSurfaceView swaps unconditionally because the buffer would be preserved. Downsides: 1) it should be set on EGL setup, thus potentially taking some VRAM without knowing beforehand if the low CPU usage mode was going to be used at all (and adding a useless copy every frame when low CPU mode is disabled), 2) it seems not to be widely supported.
3. In case low CPU is enabled, render to a FBO and just blit it on subsequent render requests. This would be more or less the same as (2), but taking VRAM only if needed. Downside: blitting plus swapping is more energy demanding than just skipping the frame.
4. Decouple process and rendering on Main::iteration() so we can call the process part unconditionally and the render part as needed. Not sure about how easy would this be and that would still require adding some more threading to the specific code of each platform.

(3) could be a transient solution until Godot main loop is rearchitected, couldn't it?

[kubecz3k]

I was using this option as well, to lower power consumption on some mobile devices... If original function was misleading then maybe it just should be renamed to something like 'set_idle_process_fps' or something?

[florix91]

Yeah would love to have it again for My apps...

On Oct 22, 2016 16:48, "kubecz3k" [email protected] wrote:

I was using this option as well, to lower power consumption on some mobile
devices... If original function was misleading then maybe it just should be
renamed to something like 'set_idle_process_fps' or something?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6727#issuecomment-255532680,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANZmYszgI2UFjbA6w1qs6HFuRCC5gDk0ks5q2iI5gaJpZM4KQFUz
.

[akien-mga]

@reduz I think The People™ wants to have this back :) If it was misleading, maybe we should readd it under a new name and/or with good documentation explaining what it can be used for or not.

[ghost]

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about it here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

[akien-mga]

@RandomShaper @reduz What should we do with this issue?

[RandomShaper]

AFAIK, _target fps_ is not coming back, so the remaining issue here is low-CPU mode not working well on Android.

I suggest to close both this and #7980 since #19304 is about the same but reported about 3.0.

[akien-mga]

Sounds good to me, thanks.