Rockbox mail archiveSubject: Re: Scrolling thread on iriver
Re: Scrolling thread on iriver
Date: Tue, 14 Jun 2005 19:18:59 +0100 (BST)
>> 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)
Would it really not be more efficient?! I'd be amazed if it wasn't.
> 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 :)
Ah :) Cool. I must check out that wiki. In the meantime I'll hack
together some modified scrolling code
Received on 2005-06-14