Messages in this thread |  | | Date | Wed, 4 Sep 1996 09:55:13 +0200 (MET DST) | From | Bernd Schmidt <> | Subject | Re: Speeding up screen output for dialog |
| |
[snip - stuff about opost_block() patch]
> A better solution would be to actually implement the put_char() and > flush_chars() methods for the console driver. What the console's > put_char() is called, buffer the characters to be printed. When the > n_tty line discpline is done sending the characters, it will call the > flush_chars() method of the tty driver, if the driver has prepared one. > You can use this method as the cue to flush the output buffer by calling > con_write().
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. This could be fixed by making the buffer larger (say, one page). But that isn't really a good solution either since it will waste one page for each virtual console. I thought about buffering output for all consoles in one common buffer but I didn't quite have the nerve to figure out how this would work with console switching, so I started looking at the n_tty.c code instead.
> In the long run, opost() should probably be written so that it takes a > pointer, a from_user boolean, and a count. This will eliminate one of > the procedure activiations per character that's in the current system.
How about implementing an opost() method for each driver, similar to the way put_char() is driver dependent? It would take a pointer to a block of characters as well as a count and would then process the characters as it seems best (either buffering with put_char() or writing directly with write() ). This way, you wouldn't need an extra buffer for the console. You'd still have a default opost() somewhere in n_tty.c for drivers that don't implement this.
Bernd
|  |