lkml.org 
[lkml]   [1998]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fast scrolling on sparc [Re: GGI Project Unhappy On Linux]
On Sat, 28 Mar 1998, Pavel Machek wrote:
> > > 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...

One minor correction: under Linux Linux takes care of the scrolling, it's done
in the boot monitor using FORTH only.

> > 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.)

The way scrolling works in the Linux sun console driver is very similar to what
was possible with GGI when I ported it to m68k. Since Suns have faster video
hardware than Amigas, you now understand why I stayed with our own fast console
driver :-)

> 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...

That's indeed possible. Feel free to join the graphics console coder team :-)

Greetings,

Geert

--
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans