[Merged] Power Saver feature

Hex

@meleu Does this answer your question?

@jdrassa I am waiting for @BuZz 's response. I have both setups at hand (with and without switch). Regarding the Animated images I would have to think some more how I can get away with it without the switch. We currently have ImageComponent to show images. How would one incorporate GifComponent ? Can I interest you in a joint venture on this?

meleu

@jdrassa @Hex @psyke83

Let's jump to conclusion: I'm OK with that being an option! :-)

But when I suggest to hide this option, I'm just giving an user point of view opinion. My only concern is with ES becoming a frontend like xmb/lakka, poluted with tons of options that casual/average users don't care and would prefer to just leave the default and don't see the option.

That being said, I think that if the text scrolls and then stops, I would label it as a bug (just like we did with the screensaver issue). But once it's fixed I believe that omit the option is the "user-friendlier" approach. If it's too complicated to "fix" this behavior, OK, leave it as an option.

Regarding to animated elements, I think that when this feature is implemented, it should setPowerSaver(false). As far as I understood @jdrassa said that this logic would be complex... Well TBH I'm afraid that such feature would bloat ES and make it heavier to use on a raspi1/zero...

Hex

@meleu Isnt the default behaviour to scroll text and stop? It doesnt stop in the middle of the scroll if that is what you mean.

Dont be confused by logic being complex. It takes less than a ms to compute logic. Processing for a ms is always better than rendering for a minute.

meleu

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

@meleu Isnt the default behaviour to scroll text and stop?

As @jdrassa said:

With regards to text scrolling, for the game description, the animation runs in a loop, It scrolls to the end, pauses for a bit, then resets back to the top and scrolls again.

I didn't really test to see this happens in your branch (will test in a couple of hours), but I think PS should keep the original behavior (scroll to the end, pause for a bit, go back to the top and scroll again).

@Hex said

Dont be confused by logic being complex. It takes less than a ms to compute logic.

I meant complex to code, not to the processor execute. :-)

meleu

@Hex Hey man! Really sorry for saying things before testing. I've just compiled and launched your branch and the game description scrolls just like the official branch (goes to the end and back to the start and scrolls again)!

Huge thanks for adding this feature and really sorry for wasting your time...

Cheers!

meleu

@Hex
UPDATE
Ooops!

The test I described above was made with video preview on. When I changed to detailed view, the text doesn't scroll at all. Maybe you want take a look at it.

Hex

@meleu \m/ :)

You guys dont ever waste my time. Your feedback is really important.

Given enough eyeballs, all bugs are shallow -- Linus Torvalds

EDIT : can you post some screenshots. That would be helpful

meleu

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

can you post some screenshots. That would be helpful

I'll try a video, give me some minutes.

meleu

@Hex sorry about the video quality, but here it is:

Hex

@meleu Firstly stop apologising. Secondly it was my mistake. Since I am using a theme that doesnt have description shown I was unaware that that is what was not working. I was under the impression that you were talking about the game name which scrolls nicely in my build:facepalm:

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?

meleu

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

So to makes things easy the description is not going to scroll.

Yeah, I think it's a fair price to pay for power saving, specially for those who build handhelds.

But now I have changed my mind about it being enabled by default. Once this change is merged in a couple of days people will come to the forums complaining about text not scrolling...

Well, after all this conversation on this thread my opinion is:

this option should be disabled by default (otherwise people unaware about this change will open topics about "issues after updating ES").
(obviously) it must have a switch to enable/disable (it's already done, I'm just putting clear that I changed my mind).

Hex

@meleu Lets talk tomorrow. I am too sleeppy to type

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.