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: Tue, 14 Jun 2005 20:47:39 +0200


On 14.06.2005, you wrote:

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

> .. like I said, all that masking/shifting logic is already in
> the lcd_bitmap function anyway. So currently we call
> lcd_bitmap for *every* *character* in the string we want to
> print (as well as iterating through the glyph into to get
> character widths). My suggested change is to just call
> lcd_bitmap *once* where src and dest are both in the
> framebuffer, and then call lcd_bitmap once more to print a
> fragment of a character at the far right (or left) of the
> rect.

> In fact, since the y-position of src and dest are identical,
> we even take out a bunch of extra shifting too (because
> currently we need to shift the font bitmap into the right
> place in the 8-bit vertical line)

You could possibly save the shifting, but not the masking. It
might be a bit more efficient, but imho not that much.
It would also require additional code in lcd_bitmap(), since
the current implementation always starts reading at bit 0 in
the source bitmap.

Btw, the jerky scrolling you observed is certainly not a problem
with the lcd code performance, but rather caused by other
threads not yielding frequently enough. Rockbox uses a simple
cooperative round-robin scheduler, and if even one single thread
holds the cpu for too long, the scrolling can't be smooth.

Regards, Jens

Received on 2005-06-14

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy