[Merged] Power Saver feature

[dankcushions]

@Hex said in Testers needed :: Power Saver features :: PR #172:

So to makes things easy the description is not going to scroll. Asking the description to move is same as not having PS. Frames need to be rendered to show the moving text. This is a side effect. A switch would solve this trouble. Users will have to decide what is important for them. Both features are mutually exclusive just like Video preview and PS.

Guys what do you think about this. Can anyone suggest a better way to handle this?

in my opinion, when you highlight a game, the text should scroll to the very end, then go back to the beginning, and then stop (at this point i guess power saving kicks in). That way if someone wanted it to scroll to the end again, they would just have to re-highlight it in the list. that's intuitive to me - in fact i think that's how i've seen it handled in other interfaces. something constantly scrolling can be distracting.

OR, powersaving doesn't start until the 'screen dim'/screensaver function? could that work?

i don't like the idea of any new options added to ES. i think it's cluttered already.

[Hex]

Waiting for powersaver to kick in after screensaver is very bad for video screensaver and it defeats the purpose altogether of PS. PS is ment to act like a screensaver without modifying the screen. It just allows CPU to sleep

[dankcushions]

@Hex ok, then i vote for my first suggestion :)

[pjft]

Let's keep the conversation here rather in GitHub then :)

My take on the descriptions not flowing is mentioned there, but I'll repeat it here:

• I believe that no default option should remove or reduce functionality from the users. From what I'm reading, this does happen in some situations, so I am not ready to support this becoming the default as it is. Always bear in mind that, while any particular change may improve the life for several people, there are several users for which ES is just fine as it is. In this particular work, people with RPis 2 and 3s won't really "feel" any impact from this change unless they're actively monitoring CPU cycles and such (which, let's be fair, isn't what a "normal" user will do unless they're a bit OCD).
• I agree that, regardless of whether this is an option or not, or whether this is a default or not, this can certainly be the default for when this is in screensaver mode for DIM and BLACK. I'll even expand more: I think that this can be the default for screensaver mode when using OMXPlayer, as it has nothing to do with ES in terms of rendering pipeline.

My recommendation, though, is to try to understand - and enumerate exactly - what functionality does this not allow for, and then working together to make that work, or at least designing a proper, working experience. Can someone help compile that?

If there are animations that don't work when in PS mode, I'd push for changing them from scrolling to flipping after a while, in PS mode - meaning, rather than slowly scrolling for a few seconds, have them just "flip" (as in if you'd press "page down" on it) to the next section.

Alternatively, can we not just get more power savings by forcing ES to render less frames per second during the animations? Or alternatively, can we not be in PS mode, but if there's an animation to be triggered, it is smart enough to run the animation (scrolling) and then just stay in low consumption mode if there's nothing to do?

I see mentions of code to "disable" and "enable" PS before and after animations. I believe the right thing for it would be to be centrally - and transparently - controlled rather than each individual component to have to replicate the exact same thing.

I wonder how hard it'd be to rearchitect the whole rendering pipeline so that it is overall smarter, and we only effectively render "dirty" (changed) objects, and objects on top of them? Would that alleviate the burden?

I mean, surely a scrolling text box wouldn't be responsible for 20% or so CPU consumption?

A few questions here.

Thanks for working through this.

[cyperghost]

@pjft @Hex @dankcushions

I believe that no default option should remove or reduce functionality from the users. From what I'm reading, this does happen in some situations, so I am not ready to support this becoming the default as it is. Always bear in mind that, while any particular change may improve the life for several people, there are several users for which ES is just fine as it is. In this particular work, people with RPis 2 and 3s won't really "feel" any impact from this change unless they're actively monitoring CPU cycles and such (which, let's be fair, isn't what a "normal" user will do unless they're a bit OCD).

That's the point I always gave feedback to. The PS option is more usefull for RPi0/1 builds and even "essential" for devices that get powered via battery. I think if it would made be option via selection menu and a message would be displays like "be aware, there are some effects on GUI but it will save CPU cycles" then it should be okay, even for the normal user.
There are other options which seem sometimes difficult to understand. Normal user also asks... What are the gamelist options for? What means parsing the gamelist only? I think small info notes if you activate/deactivate can help unexperinced users und may avoid backtalks in the form.
What do you think of?

I agree that, regardless of whether this is an option or not, or whether this is a default or not, this can certainly be the default for when this is in screensaver mode for DIM and BLACK. I'll even expand more: I think that this can be the default for screensaver mode when using OMXPlayer, as it has nothing to do with ES in terms of rendering pipeline.

That's imho a question that should be cleared by the developers ;) I'm just an average user.

[Zigurana]

I've made this comment earlier on the Github thread:

There are several ways to cope with the scrolling text issue. For instance, you could think of linking it with the screensaver time-out. This to me seems the more natural solution, going into PS mode only once the screensaver kicks in.

That way, we also circumvent the video display issue: If you select a dim/black screensaver, you also get PS, if you select video-screensaver, you're better wired to a wall...

All in all I think we should strive to limit the amount of options, especially for features that are supposed to work under-the-hood like this one. If we want to signal it explicitly, we could consider renaming the dim/black screensaver types to "DIM (POWERSAVER)" and "BLACK (POWERSAVER)".

[jdrassa]

@pjft said in Testers needed :: Power Saver features :: PR #172:

If there are animations that don't work when in PS mode, I'd push for changing them from scrolling to flipping after a while, in PS mode - meaning, rather than slowly scrolling for a few seconds, have them just "flip" (as in if you'd press "page down" on it) to the next section.

As is, I don't think this would work. Power Saver works by switching input event processing from polling to waiting, essentially halting all logic until another input event occurs.

I wonder how hard it'd be to rearchitect the whole rendering pipeline so that it is overall smarter, and we only effectively render "dirty" (changed) objects, and objects on top of them? Would that alleviate the burden?

I mean, surely a scrolling text box wouldn't be responsible for 20% or so CPU consumption?
This approach could help, but would be a very large undertaking. The complex problem is determining what is "dirty". It is not just the component that requires animation. It is anything that overlaps with that component and potentially anything that overlaps with those. A background image (as most themes have) would likely force everything to be re-rendered.

I would hate to see @Hex's work on this get bogged down by us trying to design the perfect solution. I am OK with a Power Saver option that comes at the cost of some reduced functionality. That doesn't prevent us from learning from it and making general improvements.

[pjft]

@cyperghost Correct.

My question on the rendering pipeline was indeed more for @Hex , @jdrassa and @Zigurana who are more familiar with ES development, and could comment on the validity and worthiness of exploring any such alternative.

@jdrassa Agreed. My intent was not to increase scope (and thanks for calling out that that was how it was coming across), but more to see if there's a smaller but more manageable way to address this.

Truth be told, I was mostly thinking of whether there'd be something that could be done at the GuiComponent level to reduce rendering objects that aren't dirty - not to edit massive amounts of code.

And, once again, one thing does not preclude the other - this can certainly be launched, and we can still look into reducing the overall rendering overhead at a later stage.

I won't oppose to launching with reduced functionality - and following @Zigurana 's suggestion of, in screensaver mode, to actually default to that - provided that the reduced functionality is spelled out.

Also, @Hex : I'm pretty sure that if the video player is OMX Player you don't need to animate things, as the video rendering is a separate process. You only need to animate things if it's VLC. So that's a bonus, but I'd love to test that.

[Hex]

@pjft said in Testers needed :: Power Saver features :: PR #172:

Let's keep the conversation here rather in GitHub then :)

Agreed

My recommendation, though, is to try to understand - and enumerate exactly - what functionality does this not allow for, and then working together to make that work, or at least designing a proper, working experience. Can someone help compile that?

If there are animations that don't work when in PS mode, I'd push for changing them from scrolling to flipping after a while, in PS mode - meaning, rather than slowly scrolling for a few seconds, have them just "flip" (as in if you'd press "page down" on it) to the next section.

This is a good suggestion

Alternatively, can we not just get more power savings by forcing ES to render less frames per second during the animations? Or alternatively, can we not be in PS mode, but if there's an animation to be triggered, it is smart enough to run the animation (scrolling) and then just stay in low consumption mode if there's nothing to do?

I would like to disagree on this point. ES already does its best at rendering with as much FPS as possible (probably capping it at 60fps). I would not like to see that reduced forcefully. Its a timed process ie.

0.......0.......0......0...
XzzzzzzzXzzzzzzzXzzzzzzXzzz

Here "zzz" represents processing time and is variable from machine to machine
"X" refers to when next frame is starting to render
"0" refers to when rendered frame is shown

Since "zzz" varies per machine the frames are rendered with great precision by hooking into the clock "...". Simply said the rendered checks what time it is and decides which frame of the animation to render. So if your animation lasts a minute, renderer checks how much time is elapsed and based on that which frame to render. Without this animations would be very fast on laptop and very slow on Pi.

I see mentions of code to "disable" and "enable" PS before and after animations. I believe the right thing for it would be to be centrally - and transparently - controlled rather than each individual component to have to replicate the exact same thing.

I agree on this but I dont know at present how that could work.

I wonder how hard it'd be to rearchitect the whole rendering pipeline so that it is overall smarter, and we only effectively render "dirty" (changed) objects, and objects on top of them? Would that alleviate the burden?

It would help a lot. The renderer hasn't been touched in 2 years.

I mean, surely a scrolling text box wouldn't be responsible for 20% or so CPU consumption?

What is being done to support that feature is responsible for the increased CPU consumption.

[Hex]

@cyperghost I am not interested in adding more and more options to the menu. These quickly become stagnant as the user only looks at it once and never again. I would like to suggest having a screen like setup where user can configure all one time options just like Configure Input, which is never used unless you screwed up.

[pjft]

@Hex Sounds good, no further questions.

Still, I'd like to test whether PS can be turned on if using OMX Player as the video player in video gamelists - except that the text won't scroll, and same with OMX Player as the screensaver player. I imagine with VLC you'll need to have it off, but do test that.

Also, as mentioned, I don't think it should be the default at this stage, though it is looking good so far!

[Hex]

@Zigurana said in Testers needed :: Power Saver features :: PR #172:

I've made this comment earlier on the Github thread:

There are several ways to cope with the scrolling text issue. For instance, you could think of linking it with the screensaver time-out. This to me seems the more natural solution, going into PS mode only once the screensaver kicks in.

So you are suggesting that scrolling occur when screensaver starts? that wont help.

That way, we also circumvent the video display issue: If you select a dim/black screensaver, you also get PS, if you select video-screensaver, you're better wired to a wall...

Not necessarily. Power savings reduces overhead processing and hence heating of cpu. Even walled devices are helped. BTW ES utilizes 60% on Pi zero while OMX hovers on 10% with video. So you see.

All in all I think we should strive to limit the amount of options, especially for features that are supposed to work under-the-hood like this one. If we want to signal it explicitly, we could consider renaming the dim/black screensaver types to "DIM (POWERSAVER)" and "BLACK (POWERSAVER)".

On one hand I do not think combining options is a good way to proceed. On the other I am against increasing options in ES

[Hex]

@jdrassa said in Testers needed :: Power Saver features :: PR #172:

@pjft said in Testers needed :: Power Saver features :: PR #172:

If there are animations that don't work when in PS mode, I'd push for changing them from scrolling to flipping after a while, in PS mode - meaning, rather than slowly scrolling for a few seconds, have them just "flip" (as in if you'd press "page down" on it) to the next section.

As is, I don't think this would work. Power Saver works by switching input event processing from polling to waiting, essentially halting all logic until another input event occurs.

It can also have a timeout parameter. That is how it is currently handling screensaver. Waiting timesout just before screensaver timeout and triggers screensaver.

I wonder how hard it'd be to rearchitect the whole rendering pipeline so that it is overall smarter, and we only effectively render "dirty" (changed) objects, and objects on top of them? Would that alleviate the burden?

I mean, surely a scrolling text box wouldn't be responsible for 20% or so CPU consumption?
This approach could help, but would be a very large undertaking. The complex problem is determining what is "dirty". It is not just the component that requires animation. It is anything that overlaps with that component and potentially anything that overlaps with those. A background image (as most themes have) would likely force everything to be re-rendered.

I would hate to see @Hex's work on this get bogged down by us trying to design the perfect solution. I am OK with a Power Saver option that comes at the cost of some reduced functionality. That doesn't prevent us from learning from it and making general improvements.

Reduced functionality can be rectified later. Given a choice between power saver and scrolling description, I will choose PS any day. Be honest, have you ever read that description?

[Hex]

@pjft said in Testers needed :: Power Saver features :: PR #172:

Also, @Hex : I'm pretty sure that if the video player is OMX Player you don't need to animate things, as the video rendering is a separate process. You only need to animate things if it's VLC. So that's a bonus, but I'd love to test that.

The video rendering is in different process but not everyone uses OMX. Animation is in GIF images instead of static box art. You could have GIFs of gameplay instead of video to reduce over head in processing.

[Hex]

@pjft said in Testers needed :: Power Saver features :: PR #172:

@Hex Sounds good, no further questions.

Still, I'd like to test whether PS can be turned on if using OMX Player as the video player in video gamelists - except that the text won't scroll, and same with OMX Player as the screensaver player. I imagine with VLC you'll need to have it off, but do test that.

Also, as mentioned, I don't think it should be the default at this stage, though it is looking good so far!

I can easily do that instead of activating it for the entire gamelist. It was kept like that because i needed it stable for testers. I now have a better grasp of the logic behind so it would be easier.

[pjft]

@Hex Sure.

I'm not sure I'm being clear, though. What I'm saying is that if you have the "UseOMXPlayer" option set to true, you can pretty much keep PS on rather than keeping it off because of VLC. Especially, if you're coming from the angle that this is useful for lower-power devices, they certainly won't be using VLC anyways. Meaning, if that setting is on, you can treat video view as a Detailed view.

And I'm not sure if that's what you're referring to, but I believe we do not support animated GIFs in ES.

[Hex]

@pjft I am interested in making it default. This means lesser problems to manage in the code/feature. Since i am coding on laptop i didnt account for OMX not needing PS disabled. I would like to test it and then i dont have to make assumptions.

I would say scrolling of description is a small sacrifice for PS. No one reads it anyways.

[pjft]

@Hex said in Testers needed :: Power Saver features :: PR #172:

I would say scrolling of description is a small sacrifice for PS. No one reads it anyways.

I see your point and the momentum behind this, but I'd rather not make assumptions on behalf of the wide number of users. We have more suggestions of it being the contrary, rather than what you claim:

• If it wasn't relevant, probably theme makers wouldn't dedicate that much real estate to it, or at least we'd see more themes without a description;
• If it wasn't relevant, people would probably not have noticed that it wasn't scrolling anyway in just this small sample, and wouldn't have voiced their concerns;

The fact that it may or may not matter to the select few that are discussing this right now does not mean that that is the truth or factual. :)

Let's try to keep this conversation and any such decisions data-driven, and - for the lack of data - let's at least try not to break things for users based on assumptions, or without a really good reason behind it other than just we'd want to make it a default.

We either come up with a solution for it to make it a default, or it will likely be a non-default option as it's bringing non-immediately-tangible benefits for a wide audience that has lived without it until now (I'm looking at everyone with a Pi 2 or 3, a Linux box, a Windows-based setup, or people who use this while plugged in), but it's breaking something that the audience has come to expect and rely on - no matter how small we may think it is.

I hate to be on the receiving end when something I dearly use is deemed to be deprecated because there are apparently not enough users using it. Google Reader: I'm looking at you.

Once again: I think this is a great thing to have, and I am extremely supportive of having it. But it is also my personal opinion that there need to be some - for lack of a better word - reasonable product standards for what is made a default or not, or at least that a lot more people are involved in making that decision - project owners included.

Us 5 or 6 in this thread, we are far from that representative quorum, as knowledgeable and involved in this as we may be in this project.

I like consensus-driven approaches - not unanimous decisions as those are rare, but ones where everyone's opinions can be shared and taken into account so that the best decision can be taken as a group and everyone can rally behind it, even if it wasn't their preference.

This is my personal opinion, no particular attachment to it, and happy to be proven otherwise or that several others have different thoughts on the guidance and share them as well.

Hope this helps.

[Hex]

@pjft I get what you are saying. I would like to clarify what I meant when i said so. PS can be implemented now and this can be worked on next. I am looking into way it can work for all.

If we implement a switch for PS, majority of the users might not even be aware of the improvements as ES doesnt carry a changelog on update.

If we dont have a switch, it will break the description scrolling. What i can do for that is reduce the scrolling timeout.

What would you suggest in this case?

[meleu]

@Hex said in Testers needed :: Power Saver features :: PR #172:

If we implement a switch for PS, majority of the users might not even be aware of the improvements as ES doesnt carry a changelog on update.

As it is the RetroPie's EmulationStation, the next RetroPie release notes can have a note about it.