ant@mks.com (Anthony Howe) (06/22/91)
I don't know what I'm doing wrong but I can't seem to get fast screen updating routines like the ones used in Elvis or Levee. Can someone enlighten me on the technique used. Maybe even the screen module. - ant -- ant@mks.com Anthony C Howe Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9 "Fate favors fools, small children, and ships named Enterprise" - Riker
orc@vpnet.chi.il.us (david parsons) (06/24/91)
In article <1991Jun22.165241.2707@mks.com> ant@mks.com (Anthony Howe) writes: |I don't know what I'm doing wrong but I can't seem to get fast screen |updating routines like the ones used in Elvis or Levee. Can someone |enlighten me on the technique used. Maybe even the screen module. I don't know about elvis, but the way levee does fast screen updating is via a combination of semi-deranged update optimisation and cutting way down on the number of write() calls (so I can run it from the modem port) When levee starts up, I allocate a large buffer [ROWS*COLS+FUDGE], then for my redrawing, I write the *entire* update into the buffer - including terminal control - then write() it out in one fell swoop. It's pretty close to the speed of Bconout(), plus it's redirectable to other devices. The screen updating, btw, is the only really good bit of levee - some of the file-io and internal file managing code is, well, just about as bad as you can get and still have working code (chedit has "abandon all hope" written over it - this warning also applies to levee.) __ .david parsons \/