[Merged] Power Saver feature
-
@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
-
-
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 animationsMAX 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?
-
@cyperghost Nice suggestions. Lets see what others think.
-
Why would you want to disable PS?
-
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.
-
@Hex Does PS stop the animations or no longer?
-
@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).
-
@hex and does the text animation in the text list Component also scroll if needed?
Is it "once" or is it timer related?
-
@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.
-
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.
-
@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.
-
@jdrassa Currently PS is tracked using cycles/iterations. This is being shifted to timeout based system. When PS was thought of and developed, I had no need for description to scroll and never noticed it as I never read it. Hence a cycle based approach was easiest to implement. Now setting a timer based would be better so shifting to timer based.
-
Changelog :
- PS is moved from Cycles based to Timer based control
- 4 PS modes added: Disabled/Default/Enhanced/Instant
- Moved PS to Core module.
- Moved PS handling to VLC playback from VideoGameList
Testers: Since I squashed commits before refactoring
git pull
will not work. Kindly Delete directory and start over from clone.Thank you to all those who have helped to test, provided valuable feedback and make this possible.
Feature is now quite stable. Works well with Video screensaver and previews.
Binaries :
-
@hex I'll test :)
-
Pi Zero binary is also available now. Latest ES + PS
-
@hex said in Testers needed :: Power Saver features :: PR #172:
Pi Zero binary is also available now. Latest ES + PS
Yeah! Now I'm able to join! :-)
This pi zero version works for pi1 as well, right?
-
@meleu Yes PiZ/1 binary works for both. Pi2/3 has a different binary
EDIT : As it so happens PiZ/1 binary works on Pi3 too.
-
@hex Thanks for the binaries, I will upload them to my github ES binary archive :)
Small report: I've registered no breaks during ES run but to be true my ES settings are only small footprint (No game description, no Videos, just a bit background music). I tested the mostly the "instant" set.
- Number of games per emu system never occours in instant mode only (I think that is intended to be ... in instant mode)
- If we start a rom the display resolution of the background theme will be instantly zoomed in (cosmetic effect) and it is not matter of theme itself
All in all the timers are working:
- Default timer ~ 10 to 12sec and ES falls back to 2-3% CPU usage
- Enhanced timer ~ 5 to 6sec and ES falls back to 2-3% CPU usage
- Instant "timer" ~ <1second ES falls back to 2-3% CPU usage
What is conspicuous if ES is frehsly started the CPU usage can be downed to 0,3% after a ROM was started it never goes back less then 2-3%. Do you have any suggestions for this behaviour?
Thank you for creating this
EDIT:
Energy saving aspect
PS disabled
Voltage: 5,25
Amps: 0,48-0,53PS enabeld (instant)
Voltage: 5,25
Amps: 0,38-0,42 -
This feature is ready and I have squashed commits. I have provided binaries to test. I will be asking BuZz to merge this asap, provided no bugs are found in a day or two.
Testers : List of things to test
- Video previews work with all combinations of VLC/OMX an 4 PS Modes
- All screensavers work with all combinations of VLC?OMX and 4 PS modes
- Default Mode behaviour is acceptable
- Instant changes Transition style to instant and disables the carousel transitions
- ES never crashes while normal testing.
Note : Binaries have PS debug code so if you want to see when PS is triggered, launch my binaries using ssh so you can see the stdout. There is a small animation in the terminal to determine when PS kicks in. It cycles over these 4 characters
/ - \ |
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.