[lkml]   [1996]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Speeding up screen output for dialog

On Wed, 4 Sep 1996, Richard Henderson wrote:

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


 \ /
  Last update: 2005-03-22 13:38    [W:0.056 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site