Rockbox mail archiveSubject: Re: Testers wanted: up to 50% greater battery life
Re: Testers wanted: up to 50% greater battery life
Date: Tue, 29 Jul 2003 18:29:23 +0200 (MEST)
> The magic is pretty simple: the wps thread does more mork than we want.
This does have such a dramatic effect? Whoa! Did you measure the current?
> The first cut battery extension just suspends scolling (without destroying
> the scroll infomation already calculated) and blocks the wps thread by
> waiting for keyboard input, after the backlight timeout has elapsed.
> The second cut will restore scrolling and screen updates, but defer
> settings savings.
You may exploit partial screen update instead of the full thing, if not
> A good compromise might be to save only that information that really can
> change, and save it (or as much as possible) to the RTC memory, if in fact
> saving to the RTC memory is faster.
Please bear in mind that not all models have RTC. (The players)
> Another compromise would be to defer
> saving settings (perhaps in another thread for code cleanliness) to
> like once a minute. Another would be to save changes on power down.
For RTC setting, this is the way to go, I think (save on power down). Do we
get the stop button first? In that case, we can save it on stop.
> Each possibility has tradeoffs in terms of work done versus loss of
> settings changes in the case of power down. I'm willing to lose the last
> of volume changes and track offset for 50% more battery.
Please not the track position, this would render resume useless.
> A related problem is that the wps thread is responsible for polling the
> mpeg thread for track changes, and updating directory information. I'd
> have the mpeg thread take care of this, as it's not really related to
> /display/ issues, and the mpeg thread, I think, wouldn't have to poll.
Yeah, send a message from the mpeg thread to the wps or so.
> A more drastic change would be to make the GUI input and wps display
> completely seperate threads; this might in addition address my issues with
> occasionally delayed reaction to key-presses.
I'd welcome that, especially for 8 MB the responsiveness is pretty bad on
startup, when the big buffer gets filled.
> Thought and comments on the above are of course invited.
I just tried. ;-)
-- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-PostReceived on 2003-07-29