> > Exactly, this is what I did first. I added a 256 byte buffer to
> > struct vt_struct, and added flush_chars() and put_char() calls to the console
> > driver. This was already faster, but there were some things I didn't like.
> > First, you could still watch the cursor jump from one 256 byte block to the
> > next while the screen was redrawn.
>
> If the speed problem is almost entirely due to moving the cursor,
> you don't need to do any buffering, just keep track of the cursor
> in software and sync the hardware in flush_chars().
Right, I had the same idea yesterday, and it's actually trivial:
rename con_write() to do_con_write(), add a parameter do_set_cursor
and make con_write and put_char call this routine with either 0 or 1
in the do_set_cursor parameter. Sorry, I don't have a patch, and I didn't
do benchmarks, but subjectively it feels faster than the original code,
but a bit slower than my previous patch (function call overhead, I
suppose). This is so simple, maybe we could put that in 2.0 and attempt
to make a better fix in 2.1?
BTW, put_char() simply loses characters when the terminal is stopped, while
write() returns the numbers of bytes written and allows the operation to
be retried. Is this a bug?
Bernd