Rockbox mail archiveSubject: 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 <rockbox_at_diffenbach.org>
Date: Wed, 30 Jul 2003 11:20:19 -0400
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
> 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