>For static images, the faster the better; for scrolling images, you want
>to scroll an integer number of pixels per frame [typically one] unless
>you're doing tricky fractional-dot techniques.

> After you've got all that stuff working right, then you can start
worrying
> about the higher-level issues of scrolling, flashing, blinking and the
> types of information you'll present. Note that you may have to modify
your
> display refresh algorithm depending on the kind of motion or effects
you're
> trying to achieve.

>Your last point is extremely important, though I think you need to
"worry"
>about the higher level issues before you design the circuit.  For
example,
>unless you have a single scan which goes from one edge of the screen to
>the other, you will need to watch out for "seams".  For example, if you
>have a 15 dot high display which is wired as three groups of five scanned
>rows, you will need to take special measures in your scanning if you wish
>to avoid visible seams between these groups.

>For example, the easiest method of avoiding seams
>requires that you approximately double your display buffer allocation if
>you use a bitmap; if you're converting text-to-bits as you scan, then you
>may not require the extra buffering but your algorithms will be more
>complex.

Hmmm, Interresting. I actully just made a LED panel and I'm having some
problems. When the picture is moving the dots seems to be double (is this
what you call "seams"). I fount out that I could remove this by setting
the
refresh rate down to once per frame. But then I get flickker due to the
low
refresh rate.
What can I do to prevent this when I change the refresh rate?
And how these special refresh algorithms working?
Can the problem be solved by double the display buffer, and how?

Thanks in advance

   Lars

----------------------------------------------
email: LJ@POBoxes.com
----------------------------------------------