Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Soft Scrolling & CPU usage

Soft Scrolling & CPU usage

From: <for_spam_at_gmx.de>
Date: Thu, 2 Jan 2003 03:44:51 +0100 (MET)

Hi there,

some comments about soft scrolling:

I wondered that one could set scroll-frequency value just to "10".

I read,that softscrolling at "pixel step size" would cause cpu problems at
rates
>10 updates per seconds and a patch someone posted some time ago for
increasing
that value was cancelled due to this fact.
We must keep in mind - we are on "embedded platform" so CPU cycles IS an
issue.

I took a look at the source (though, i`m not very good in programming - just
made some
demo-coding on c64 decades ago and now just do sysadmin-programming-stuff :)

I don`t really wonder, that we have a speed/performance issue here.

In lcd-recorder.c:

lcd_clearrect(xpos, ypos, LCD_WIDTH - xmargin, h);
lcd_putsxyofs(xpos, ypos, s->offset, s->line);
lcd_update();

...being called for every single "pixel scroll step".
So we have complete font rendering and all that stuff for every call to the
scroll
routine - phew - much unnecessary processing overhead IMHO.
Am I right at this point ?

I would suggest doing the text/font-rendering stuff (ascii to pixel) to some
hidden "pixel-buffer" and copying that to the appropriate pixelposition in
GDDRAM, or doing direct
manipulation on GDDRAM (bit rotating/shifting of the bytes!?)
(for GDDRAM see: http://rockbox.haxx.se/docs/ssd1815r1_5.pdf)

Maybe, doing this stuff in assembler or even "code down" parts of the
scroll-routines in a
"flat" manner could make sense here ?

e.g. (don`t know sh1 assembler):

LOAD BYTE FROM (PIXBUFFER-BASEADDR+COLUMNNR+LINENR*BUFFERWIDTH)
BITWISE ROTATE RIGHT/LEFT (TAKE ACCOUNT OF CARRY BIT) N Times
STORE BYTE TO (PIXBUFFER-BASEADDR+COLUMN+LINE)
LOAD BYTE FROM (PIXBUFFER-BASEADDR+COLUMNNR+1+LINENR*BUFFERWIDTH)
..
...
....
LOAD BYTE FROM (PIXBUFFER-BASEADDR+COLUMN+0+(LINE+1)*BUFFERWIDTH)
BITWISE ROTATE RIGHT/LEFT (TAKE ACCOUNT OF CARRY BIT) N Times
..
...
....

Just an stupid example.
Since we don`t have many pixels/bytes to scroll, we wouldn`t end with
megabytes of
code.

Perhaps, this would make it necessary to some major rewrite of the lcd
display
manipulation routines - but perhaps this could led to overall better
performance
and free some cpu-cycles.

What do you think ?
regards
Roland

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
Received on 2003-01-02

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy