|
Rockbox mail archiveSubject: Re: Scrolling thread on iriverRe: Scrolling thread on iriver
From: Jens Arnold <arnold-j_at_t-online.de>
Date: Tue, 14 Jun 2005 19:51:09 +0200 Hello dave_at_beermex.com On 14.06.2005, you wrote: >> Am I right in thinking that scrolling text on iriver causes >> it to 'puts' the entire string each time it scrolls it, even >> by one pixel? Is that efficient? Seems to me that it would be >> better to implement the scroll using something like a memcpy >> from the framebuffer and just use the string-print logic to >> print out the far right-hand column that scrolls in (or left >> hand if scrolling right). > In fact, since all the code and optimisations are in > lcd_bitmap anyway, this could just be achived by adding a new > arg (src_stride defaulting to nx) and doing a lcd_bitmap with > src_stride == LCD_WIDTH and src actually pointing inside > lcd_framebuffer appropriately. > src_stride could be a useful addition anyway, for 'partial' > blts for example. could be handy in the future for advanced > graphical wps stuff perhaps (perhaps not..) I don't think that implementing _line wise_ scroll directly in the framebuffer will be more efficient than simply print the whole string, because you can't use a simple memmove() (apart from that we don't have memmove and memcpy won't work). More often than not a text line boundary won't correspond to an LCD line boudary, so you would have to do a lot of bit masking and combining. However, an added stride parameter definitely has advantages, that's why it is included in my proposal for a new graphics api, see http://www.rockbox.org/twiki/bin/view/Main/GraphicsAPI I'll soon start working on it :) Regards, Jens _______________________________________________ http://cool.haxx.se/mailman/listinfo/rockbox Received on 2005-06-14 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |