Rockbox mail archiveSubject: Re: Scrolling thread on iriver
Re: Scrolling thread on iriver
From: Jens Arnold <arnold-j_at_t-online.de>
Date: Tue, 14 Jun 2005 19:51:09 +0200
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
However, an added stride parameter definitely has advantages,
that's why it is included in my proposal for a new graphics api,
I'll soon start working on it :)
Received on 2005-06-14