|
Rockbox mail archiveSubject: Re: Scrolling thread on iriverRe: Scrolling thread on iriver
From: Jens Arnold <arnold-j_at_t-online.de>
Date: Tue, 14 Jun 2005 20:47:39 +0200 Hello dave_at_beermex.com 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 _______________________________________________ http://cool.haxx.se/mailman/listinfo/rockbox Received on 2005-06-14 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |