I'm new to rockbox and used my last 24 hours to go through the whole
code. Myself owns an Iriver H300. I think rockbox is very great now, but
could be much better :) (Jpeg, Video)
So here is what I think about the lcd_update() Speed problem:
The LCD can handle one Pixel per 150ns (Datasheed->Writecycle). That
would be around 120frames per second. I think, the problem is in the
code. For every Pixel send to LCD, Chipselect selects SDRam, reads one
byte, selects LCD and writes byte there.
The whole procedure with switching Chipselects for every byte (aw sry, i
mean word, pixel) is consuming many time we dont have...
I wrote a very small speed-test, a few loops with just increasing colors
(nearly no calculations, just to have it look funny) with LCD_WIDTH
calls to lcd_update(). This loop dures around 28 seconds with CPU not
boosted and around 10 seconds with CPU boosted.
Just for fun with CPU Idle:
2 mins 24 -> 144 seconds.
Oh maybe a kind of bug: My plugin only has this for-loop, and standard
plugin api. HD doesnt stop spinning! (it seems like nothing else than
plugin code is executed)
And.. kind of mistake in my program: it just runs from 0 to
LCD_WIDTH-31, so 189 loops.
Idle 1,3125 fps
Code, just if someone wanna use it ^^ (verry crappy)
So only calculation done is LCD_RGBPACK with few bitshifting... Not to
forget the loops, with few clockcycles per run.
So my idea is:
What about buffering the whole lcd_framebuffer in internal SRAM?
(64kbyte are not enough... so we have to put second 32kbyte directly
after the 64kbyte to connect these 2 together.
I dont really know.. Does rockbox use sram for some stuff?
If so, on lcd_update move away the crap, store lcd_framebuffer in there,
write to gram and last but not least (else player would maybe hang ^^)
restore crap from the beginning.
This should be a little bit faster... But I cannot implement it because
of my low coding skills (PHP is more what i can do...)
What do you think of my idea?
Received on Wed Dec 28 01:08:36 2005