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