[Merged] Power Saver feature

[jdrassa]

@hex Please correct me if I am wrong, but is the only difference between Minimal, Full, and MAX the time delay between switching from SDL_PollEvent to SDL_WaitEventTimeout?

If so, I have a suggestion.

• PowerSaver mode is always on. There are no menu options to enable or configure it.
• The default delay before enabling PowerSaver mode is the users configured Screen Saver delay.
• If a user wants to change the delay to achieve more power savings, they can modify es_settings.cfg directly to specify a different value. This process can be documented on the RetroPie wiki. This is how the hide splashscreen option works.

I think this approach will give the most benefit to all users without changing functionality, while still giving users who want more power savings the ability to do so.

[Hex]

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

@hex Please correct me if I am wrong, but is the only difference between Minimal, Full, and MAX the time delay between switching from SDL_PollEvent to SDL_WaitEventTimeout?

@jdrassa Very simply, yes. Although there is an enforcer in addition to the counter. Enforcer ensures counter is overridden when PS is disabled and Counter ensures trailing animations after last event. Both are equally important.

If so, I have a suggestion.

• PowerSaver mode is always on. There are no menu options to enable or configure it.

Auto scroll doesnt work in that case

• The default delay before enabling PowerSaver mode is the users configured Screen Saver delay.

Screensaver delay is at minimum 1m so switching timeout goes from 12 secs to 1m which is not good. Also if video screensaver is enabled PS will never be triggered (generally)

• If a user wants to change the delay to achieve more power savings, they can modify es_settings.cfg directly to specify a different value. This process can be documented on the RetroPie wiki. This is how the hide splashscreen option works.

The user base inerested in PS will be more than hide splashscreen guys. Not many users look at the documentation for latest features.

[cyperghost]

@hex Do you think it would be better to show no PS feature in main menu... so it's disabled by default and all users got a working ES as it looks like now. But create a bash-file within RetroPie menu. There you can choose between PS settings and can tell all advantages and disadvantages of each setting and ES reads out a value in a cfg file stored as you want?

I'm very intereted in the PS feature your know and I personally would enable it by default. Because I have no scrolling filenames, I don't use video preview....
I would also activate it in my Pi0 portable :)

[Hex]

@cyperghost I dont know if that is possible. Are there any Es settings currently in Retropie-setup?

[cyperghost]

@hex Well you load Themes for ex. within RetroPie-Menu and activcate them through ES
So yes items for ES are changed through RP-Menu

and yes .sh files can be located to ~/RetroPie/retropiemenu/ and they are visible and executable by default. So why not using this way? You can even create an icon for your set and descripe it in gamelist.xml - very nifty possibilty to create a settings menu :)

Since we know How to: Restart ES via bash script an activation/change of values of ES is also possible :)

So you may create a file names advanced_settings.xml (is there a good place to locate??) and can descripe option there and it could be usefull for future tweaks. For changing file advanced users can do edit manually and/or you write a small bash-script that also explains every option and does a restart automatically after settings were done.

---

Here you can also find answer of what is ment by EUREKA

[Hex]

@cyperghost Themes are loaded via Retropie menu but selected using ES alone. I dont think it is a viable solution.

[cyperghost]

@hex If ES is executed it checks presence/values of advanced_settings.xml one time. Is there is a tag like

<!--
      Hello,
         I am a multi-line XML comment
         I want to tell you a new feature of ES, the powersaver....
        0 = disabled
        1 = min, value Video support works, Scrolling not....
        9 = may the force be with you
               -->

<powersaving>
  <mode>0</mode>
  <timeout>90</timeout>
</powersaving>

or file is missing then PS is disabled.
via batch script and xmlstartlet you can change XML values easily and then force a restart. I think it's a possible solution and you don't need to mess around with explanations pop ups within ES but of course ES must be prepared for the value you've setted in PS-mode.

Of course it's your decision but it will also help to keep ES menu slim but it's still easy configurable by scripting menus.

[Hex]

@cyperghost I do not want to complicate this further. It has already been decided to have PS enabled by default and a timeout set such that description scrolls. I want to have a setting for people not using/caring about descriptions, hence the Full option. I might think about MAX:EXP option for instant and no carousel users (Might not be implemented). Timeout access shall not be available to user as wrong setting will render ES unusable.

So None/Minimal/Full are three options thought of being implemented for certain. I want your input on changing the names of these modes if necessary. I had name changing suggestions at a later stage while submitting additional animations. I dont want to repeat that. Hence if you have better suggestions for Mode Names, let me know.

[Zigurana]

@hex
Good idea's all around, even better to come to a decision 😀.
Question: For users, there is no difference between none and minimal, right? Why do we need both?

I would go for default / Improved

[cyperghost]

@zigurana @hex

I would go for usecase disabled/comfortable/portable

[Hex]

@Zigurana

None -> PS is disabled always
Minimal -> PS is enabled after Description has scrolled once (approximately)
Full -> Game name scrolls, Description doesnt scroll
MAX:EXP -> PS has very short trigger time. Great for instant and no carousel transition users. For those who dont care about animations

MAX might not be implemented, who knows. There is currently just one bug. PS isnt disabled while running scrapper (Fetch MD). That needs to be taken care of.

Timeouts

• MAX -> 20-40 cycles (Needs testing to reduce range)
• Full -> 100-200 cycles
• Min -> 10-12 secs ~ 1000-1200 cycles
• None -> Not needed

Do you have any suggestions for Mode names?

[Hex]

@cyperghost Nice suggestions. Lets see what others think.

[Zigurana]

Why would you want to disable PS?

[Hex]

I dont know. I think having an option to disable it prevents complaints about unexpected behaviour. Another reason would be if we decide to default it no None while merging.

[pjft]

@Hex Does PS stop the animations or no longer?

[Hex]

@pjft PS doesnt stop animations if running in Minimal Mode, Description scrolls once. This would ideally be the default if we are leaving PS enabled in Default setting (first run).

[pjft]

@hex and does the text animation in the text list Component also scroll if needed?

Is it "once" or is it timer related?

[Hex]

@pjft if you mean Game name text in game list then it does scroll nicely.

It is timer related. If the game description is way too long, it will halt in the middle. I am accounting for on an average 7-8 secs scroll, which should be sufficient for long desciptions.

[Sano]

Hi guys,
From what I'm seeing, there have been quite a few topics the last few weeks about increased CPU usage, heat problems and even lag on ES.
A lot of features have been implemented recently, with a probable impact on resources.

AFAIK it's a frequent milestone in software dev : the base code works great, then a bunch of features are added, sometimes introducing bugs or performance impacts.
Not that the new features are badly coded, but they put the emphasis on a function of the base code that was not intented/coded to work with the new features, hence very non optimal in this new context... The solution would be to modify the base code.

Anyway, from my user point of view, it's not about power saving, but general optimization.
I run @Hex ES version for a few weeks now, and I'm very happy with it.
Thanks again for your work on this.

TL;DR : I'm seeing PS as a natural code optimization rather than a feature to save battery life. Therefore I vote for it to be default, and allowing to disable it in case of the behaviour induced doesn't match the user needs.

[jdrassa]

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

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

If so, I have a suggestion.

• PowerSaver mode is always on. There are no menu options to enable or configure it.

Auto scroll doesnt work in that case

When I suggested it is always on, I meant that there wouldn't be a 'None' option. It would still function as it does not, hence the suggestion of a default (and configurable) delay.

• The default delay before enabling PowerSaver mode is the users configured Screen Saver delay.

Screensaver delay is at minimum 1m so switching timeout goes from 12 secs to 1m which is not good. Also if video screensaver is enabled PS will never be triggered (generally)

This was just a suggestion, that would ensure that no existing functionality is effected.

• If a user wants to change the delay to achieve more power savings, they can modify es_settings.cfg directly to specify a different value. This process can be documented on the RetroPie wiki. This is how the hide splashscreen option works.

The user base inerested in PS will be more than hide splashscreen guys. Not many users look at the documentation for latest features.

While I agree that many users will be interested in PS in some form, I'd argue that it is a much smaller number that will be interested in changing the settings. For those that are, they are likely to only ever change it once.

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

Timeouts

• MAX -> 20-40 cycles (Needs testing to reduce range)
• Full -> 100-200 cycles
• Min -> 10-12 secs ~ 1000-1200 cycles
• None -> Not needed

When you say cycles, I assume this means iterations of the animation loop based on reading the code. This really should be time based. Otherwise, the timing is going to vary based on the power of the users hardware.