From: db3l@ans.net (David Bolen)
Subject: Re: TE/2's slow screen display in vt100 emulation
Date: Wed, 7 Oct 1992 15:51:03 GMT
	<3998@copper.Denver.Colorado.EDU> <BvrIuM.35@ecf.toronto.edu>
Organization: Advanced Network & Services, Inc. - Elmsford, NY

In article <BvrIuM.35@ecf.toronto.edu> tee@ecf.toronto.edu (TEE LUNS) writes:

>    The problem is that TE/2 uses the VIO scroll functions to scroll the
>screen. In a windowed session, this becomes a call to bitblt the actual
>screen, which is a rather slow operation. Text display can't go on in the
>meanwhile.
>    What I imagine kermit does (and indeed, what I do in TEDP) is do all
>writing to the shadow video buffer, and do scrolling internally - i.e. no
>calls to VioScrollUp(?). This would be nice and fast, but of course the
>text never goes to the screen either. So, the code that draws to the shadow
>buffer clears a semaphore every time it changes anything. A second thread
>waits on that semaphore, and copies the contents of the LVB to the screen
>whenever it goes clear.

Actually, I've done both methods and the Vio calls are *faster* in a
Vio window when basic scrolling is involved.  For updating portions of
a screen I think it's pretty even.  The method you describe is the
traditional way of handling output under DOS, and does improve things
under OS/2 in a full-screen session.

What is important though, is to remove as much of the overhead for Vio
calls as you can.  That means calling Vio for chunks of characters
rather than a single character.  What may be happening is that TE/2 is
using Vio calls for every character, or small group of characters it
gets from the COM port, which is inefficient.  I was able to improve
some screen output in one emulator by up to a factor of *6* just by
removing a Vio call per character and changing it into a call per as
large a set of characters as I could put together.

>    There are problems though. The text is rendered onto the screen every
>time, so there's a little more work being done than just copying pixels
>on the screen. Of course, it's done a lot less often, but if it's the
>responsibility of a co-processed video card with time on it's hand, you
>may be taking away from the CPU what you don't have to.

Unfortunately, it can really hurt performance.  Having to fill the
entire window with new data, rather than scrolling the current window
and then filling in the last line is often a slower process,
especially if that new data has to come from the system, while with
the scroll, a co-processed card can just be given coordinates within
video memory.

In the emulator I was optimizing, I first tried using a screen package
I had written that does just the sort of access you are mentioning.
It was orders of magnitude slower than just calling VioScroll and
VioWrtChar in a window, although it was as fast if not a little faster
full-screen.  Overall though, the better choice was Vio calls.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/
Newsgroups: comp.os.os2.apps