[lkml]   [1998]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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 :-)



    Geert Uytterhoeven
    Wavelets, Linux/{m68k~Amiga,PPC~CHRP}
    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

     \ /
      Last update: 2005-03-22 13:42    [W:0.041 / U:45.384 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site