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