Rockbox mail archive

• Next message: scott: "ata -52"
• Previous message: François-Xavier Houard: "Re: Testers wanted: up to 50% greater battery life"
• In reply to: TP Diffenbach: "Re: Testers wanted: up to 50% greater battery life"
• Next in thread: TP Diffenbach: "Re: Testers wanted: up to 50% greater battery life"
• Reply: TP Diffenbach: "Re: Testers wanted: up to 50% greater battery life"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

> 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
already done.

> 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
something
> 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
minute
> 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
rather
> 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. ;-)

Jörg

-- 
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-Post

• Next message: scott: "ata -52"
• Previous message: François-Xavier Houard: "Re: Testers wanted: up to 50% greater battery life"
• In reply to: TP Diffenbach: "Re: Testers wanted: up to 50% greater battery life"
• Next in thread: TP Diffenbach: "Re: Testers wanted: up to 50% greater battery life"
• Reply: TP Diffenbach: "Re: Testers wanted: up to 50% greater battery life"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]