[Merged] Power Saver feature

Hex

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

@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.

@ruckage This information is quite useful. Only libvlc needs PS on. I will implement this

I have also made some progress regarding description not scrolling. How about it scrolling only once?

Sano

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

I have also made some progress regarding description not scrolling. How about it scrolling only once?

That was @dankcushions suggestion, and I second that :)

Hex

Game description is now scrolling once or more . I have tweaked the timings. So need to test it on all systems before finalizing.

I shall find an elegant solution for this later. At present I have delayed the time taken from the last event to when PS kicks in and reduced time description text waits to scroll.

EDIT : Please update the repo and build again

pjft

Sorry for the delay in getting back here.

I am supportive of a "scroll once, then reset (i.e. go back to the original state) and stop animating" approach. In fact, if there's a way to detect if the description text will even scroll or not (i.e. if it's bigger than the container), I'm sure that in several occasions it will fit it so there's no scrolling involved, which means PS can be on from the start on those cases.

dankcushions

just to clarify, it's not just the descriptions that scroll, but also the game titles, depending on your theme. for example, street fighter games on mame, with their crazy subtitles and version info :) i'm not sure if any other ES elements scroll.

just making sure the game titles don't get left out...

pjft

Agreed, good call. Any text that's larger than the container will scroll, I think.

But if it scrolls once and then stops at the beginning, I don't have much of an issue for the moment.

Hex

Game names were working well before. Descriptions were not. Now they are working but it is a hack as i had some work and needed it tested before that. Can everyone who can test it, GIT pull and then build.

pjft

@Hex I'll look into it in the coming days, if not sooner. Thanks!

dankcushions

tested (pi3). builds and looks fine to me! descriptions and game titles scroll fine. i don't use a video theme, so can't comment on that.

idle cpu went from 6-7% (dimmed) to 3% (dimmed/not)

cyperghost

@Hex
There is still issue with removing favorite by pressing Y button if you are alredy in favorite - even with your newest branch and pjfts newest commit.

All your features... Dimming, Blanking and CPU savings work
Scrolling I didn't test
Gamelist shows number of game entries without pressing button.

I load binary to my github repo: This is a merged branch @pjft favorite and your newest commits (4 times cherry pick). Is there a better way to reload all cherry picks with only one command? I used the command git cherry-pick abcdef12345678790 4 times

https://github.com/crcerror/emulationstation-binary-archive

Hex

@cyperghost you should use git pull --rebase to update your repository. You dont need to cherry pick every time

I have not tested my changes with the branch you are testing. If that PR gets merged first then i can test it. I will not test it on unmerged code.

pjft

@Hex I agree. That's the wise approach to take.

cyperghost

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

@Hex I agree. That's the wise approach to take.

Is it rather about:

Don't trust a binary compiled by someone else
Don't do working on a fix that may never be needed because the branch isn't merged into main release?
Annother codex or good practice I don't know about it?

@Hex
I think fix is easy ... but needs some work in looking @pjfts routines.
Anyway, I hope that my posting can be treated as alpha test.

ah.. and thanks for helping in using gitcommands

pjft

@cyperghost No, no, don't get this wrong :)

It's just that:
a) he won't have the source code to exactly debug it, by just using the binary -- we trust you that it crashes, but without the exact code, it's a bit of guesswork on his end as he doesn't know what code to look at exactly.
b) given that my current branch (and his branch) are both currently being developed, it may be that any time invested at this stage will be rendered obsolete - either because the bug may disappear, or because it may resurface while we keep developing.

As such, after one of them is merged, it's easier for everyone to have a stable code-base to use for actual runtime debugging. The best he could attempt to do right now would only be to try to replicate it on his current code base, seeing if deleting an entry from the list would trigger the same error. That way he would be able to narrow it down to the code to remove an entry from the list.

But if that doesn't work, he's kind of flying blind :)

Thanks for testing!

Hex

@cyperghost #3 definitely. You see features should inherently be isolated. Convoluted features should either be worked in a single PR or sequentially . This maintains the stability of the system. Simultaneous testing two PRs is very unwise.

Consider you are cooking two dishes. What do you think is better, making them one after another or at the same time? The prior is easier if you are making elaborate dishes that need great attention and timing. The later is easier if you are making scrambled eggs and toast because they are not convoluted; as in they dont require the same resources. Got it now?

cyperghost

@Hex @pjft
Sounds like you both are really know what you are doing. Thank you for clearing out :)

Hex

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

@cyperghost No, no, don't get this wrong :)

It's just that:
a) he won't have the source code to exactly debug it, by just using the binary -- we trust you that it crashes, but without the exact code, it's a bit of guesswork on his end as he doesn't know what code to look at exactly.

@pjft I can easily reproduce the code that he is working with. I know which commands were used to get a working copy. Problem is if that doesnt exhibit the bug.

b) given that my current branch (and his branch) are both currently being developed, it may be that any time invested at this stage will be rendered obsolete - either because the bug may disappear, or because it may resurface while we keep developing.

@cyperghost This is the main reason and my post above elaborates on this idea with an example ;)

As such, after one of them is merged, it's easier for everyone to have a stable code-base to use for actual runtime debugging. The best he could attempt to do right now would only be to try to replicate it on his current code base, seeing if deleting an entry from the list would trigger the same error. That way he would be able to narrow it down to the code to remove an entry from the list.

But if that doesn't work, he's kind of flying blind :)

Thanks for testing!

Also I am completely unaware on what they are developing and what is the expected functionality. So for me everything is unexplored territory.

If i am able to find a stable solution how would you recommend me going back to my code to implement it? I might not have the interface with his code to apply the fix.

Hex

BUG : PS should be disabled while Scrapper is running

Hex

Guys I thought of a solution. Instead of having a switch how about having options(List)

PowerSaver Mode :-

None ~~~~~~No power Saving/Full performance
Minimal ~~~Power savings kicks in after Description has scrolled once, same time-out for Systems view)
Full ~~~~~~~PS kicks in after Game name has scrolled, description may not scoll
MAX ~~~~~~Experimental; Works well with Instant transition and no carousel animation

All of these will work fluidly with all Screensavers and with Video Previews.

This is the only way I can think of that will allow proper PowerSavings settings and allow user to decide till which level is the compromise acceptable.

Zigurana

@hex
I would ask, what is the difference?
Not the difference in text elements scrolling or whatnot, but what is the difference in power saved when going from min to max?
How much battery - life do users gain?

I have the feeling that the bulk of the improvements are already achieved when usin PS=min, and now you are trying to squeeze out some more improvements that have little impact in day-to-day use.
80-20 pareto, perfect being the enemy of the good, and all that.

Despite all our work on ES, remember that users will spend most of their time (and power) while running actual emulators, not just the front-end.