Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!nucsrl!tellab5!vpnet!orc
From: orc@vpnet.chi.il.us (david parsons)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Elvis's Faster Screen Updating
Message-ID: <1991Jun24.083157.21079@vpnet.chi.il.us>
Date: 24 Jun 91 08:31:57 GMT
References: <1991Jun22.165241.2707@mks.com>
Organization: Department of Atomic Text Units
Lines: 20

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     \/