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
>> the framebuffer will be more efficient than simply print the
>> whole string, because you can't use a simple memmove()
>> from that we don't have memmove and memcpy won't work).
>> More often than not a text line boundary won't correspond to
>> LCD line boudary, so you would have to do a lot of bit
>> 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
> 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.
Received on Tue Jun 14 20:49:33 2005