Messages in this thread | | | Date | Sat, 28 Mar 1998 10:34:54 +0100 | From | Pavel Machek <> | Subject | Fast scrolling on sparc [Re: GGI Project Unhappy On Linux] |
| |
Hi!
> > 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
| |