From: Dave Hooper <dave_at_beermex.com>
Date: Wed, 28 Dec 2005 23:32:19 -0000

On the idea of storing the entire framebuffer in sram .. Yep, rockbox uses
SRAM for *lots* of stuff (mostly the lookup tables and workspaces used by
the audio codecs, as well as executable code for commonly used quick
functions, such as memcpy)

Maybe one way to speedup lcd updates is to implement some kind of
dirty-rectangle updates (but of course that won't speedup full frame
updates).

d

----- Original Message -----
From: "Matthias Larisch" <tierchen_at_eow.ath.cx>
To: <rockbox_at_cool.haxx.se>
Sent: Wednesday, December 28, 2005 12:05 AM
Subject: Idea: Speeding up LCD on Iriver H300


> Hey there!
> 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.
> That is:
> Idle 1,3125 fps
> Normal 6,75fps
> Boost 18,9fps
>
> Code, just if someone wanna use it ^^ (verry crappy)
> int i,j,c;
> for(c=0;c<LCD_WIDTH-31;c++)
> {
> for(j=0;j<LCD_HEIGHT;j++)
> {
> for(i=c;i<c+31;i++)
> {
> rb->lcd_framebuffer[j*LCD_WIDTH+i]=LCD_RGBPACK(c,j,i*8);
> }
> }
> rb->lcd_update();
> }
>
> 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?
>
> bye,
>
> Matthias Larisch
>
Received on 2005-12-29