Actually to expand on the thoughts that I was having:

I was not thinking of checking for copyrow ops, but more just
checking for any pending output with the Nagle-like algorithm.
The reason that I would want all/more operations to go through this
would be that on the TGA if I am handed more than one character at
a time, I can use the stipple mode to write 32 pixels (in a single
row) to the screen at a time and that is likely to be more than
one character.  Also some of the TGA's have a DMA host memory to
screen transfer that IIRC can transfer up to 8K of host memory to
the screen.  This all impies that the current wscons method of
handing me a single character at a time could be sped up significantly
by giving strings of multiple characters.

Hence buffering of more than just copyrow operations would be a
good thing.

Also, the same basic functionality could be extended to allowing
a generic wscons scrollback buffer, which I think would be pretty
useful.

I think that speeding up the frame buffer consoles is actually very
important as I found myself on my Multia ssh'ing in from a computer
next to it, because the console was so slow.  (And a couple of
friends have made similar comments.)

On 920403891 seconds since the Beginning of the UNIX epoch
Jason Thorpe wrote:
>
>On 02 Mar 1999 10:17:11 -0800 
> cgd@netbsd.org (Chris G. Demetriou) wrote:
>
> > The 'sun' emulator at least implements the Sun console 'normal' way of
> > picking how much to scroll at a time, ESC[<n>r (known in the Sun
> > manual pages as SUNSCRL; btw, in case anybody's watching, the name
> > wscons and the fact that it's apparently the same as the sun console
> > driver name was unintentional, or at least, not a conscious decision
> > 8-).
>
>It might be interesting to defer scroll operations, and wait for more
>scrolls to happen, up to some threshold... sort of like Nagle for the
>console :-)
>
>The algorithm could be something like checking for pending copyrows
>operations every T ticks, and processing them in a single multi-text-line
>blit.  If you get more than N copyrows requests before the interval expires,
>process them early (so you don't have to store too much state).
>
>        -- Jason R. Thorpe <thorpej@nas.nasa.gov>
>
>

 == Roland Dowdeswell
 == http://www.imrryr.org/~elric/