Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: things to optimize (was Re: Testers wanted: up to 50% greater battery life)
From: TP Diffenbach (rockbox_at_diffenbach.org)
Date: 2003-07-30


Quoting Daniel Stenberg <daniel_at_haxx.se>:

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



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa