dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Scrolling thread on iriver

Re: Scrolling thread on iriver

From: Jens Arnold <>
Date: 2005-06-14


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,

I'll soon start working on it :)

Regards, Jens

Received on Tue Jun 14 19:51:51 2005

Page was last modified "Jan 10 2012" The Rockbox Crew