> > I've seen linux text-mode emulation on ultra-sparcs. There are not
> > many machines faster than ultra. It is *slow* compared to my 486 with
> > VGA. Even if you turn of hw scrolling on VGA it starts to be too
>
> The main reason is that text scrolling is done in FORTH under Open Firmware,
> which is an interpreted language (using FCode).
Hmm, I did not know this one...
> But there are many ways to accelerate scrolling, all supported by fbcon (on
> some chipsets):
>
> - memcpy with the CPU (slow, mainly due to limited memory bandwidth. The PCI
> on my PPC is only 32 bit, 33 MHz). this is what is used if anything else
> fails
I have a machine (sun4/330), which has beatiful monitor, but due to
simple hw, only memcpy with hardware is possible. Linux scrolls
rrrreeeallly slooowwllly on this one. (You can actually easily scan
for text.)
My idea was: what about not doing scroll at all? Just synchronize
screen with internal screen buffer every 100msec or so (something like
Xterm does). Yes, it would do ugly hops, but scrolling could no longer
eat 99% of CPU time.
Imagine it this way: There are two things, framebuffer, and
shadow. Framebuffer is screen, shadow is memory (2bytes/character) (we
have it anyway, dunnno how it is called). There is counter of how many
modifications to shadow were done in last second. When there are too
many modifications, kernel gives up updating framebuffer.
Then, there are two daemons. One on realtime priority, waking every
500msec, second on lowest possible priority, running all the
time. Both do synchronize shadow with framebuffer.
What do you think? This could accelerate scrolling many times...
Pavel
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu