dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: things to optimize (was Re: Testers wanted: up to 50% greater battery life)

Re: things to optimize (was Re: Testers wanted: up to 50% greater battery life)

From: TP Diffenbach <>
Date: Wed, 30 Jul 2003 11:20:19 -0400

Quoting Daniel Stenberg <>:

> On Wed, 30 Jul 2003, TP Diffenbach wrote:
> > Oh dear. Is the update smart enough to not update non-scrolling,
> No. lcd_update() writes the full frame buffer to the LCD.
> For each 8 y-pixels there are 3 commands written, then there's one byte
> written for each pixel column.
> 8*3 + 8*112 = 920 invokes of lcd_write().
> That's also why we added lcd_update_rect() which only updates a given
> rectangle.
> Certainly we can make a function that doesn't update bytes that haven't
> changed, but the major boost tend to be to just to not call lcd_update() more
> than necessary.

I'd be interested in profiling something that updated only certain lines; of course, it would have to translate a logical line of text into calls to (probably) lcd_update_rect. That would allow us to only update lines that actually scroll/change.

> > The settings code may or may not take longer; the salient point is the

> Remember that we only write to the RTC that often. We write to disk when
> there's a actual disk activity triggered by other means.

I understand delayed_ata_write. My point is that save_settings copies each setting in struct user_settings to config_block, usually with extensive bit masking to compact the data. wps only ever changes volume and resume data, and the volume changing code and the resume changing code each call save_settings seperately.

Archos FM has a Rockbox!
Received on 2003-07-30

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy