Xref: utzoo comp.unix.questions:26886 comp.unix.programmer:479 comp.sys.att:10837 unix-pc.general:6437
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!portal!cup.portal.com!thad
From: thad@cup.portal.com (Thad P Floryan)
Newsgroups: comp.unix.questions,comp.unix.programmer,comp.sys.att,unix-pc.general
Subject: Re: Less Optimized Curses
Message-ID: <35926@cup.portal.com>
Date: 14 Nov 90 12:50:48 GMT
References: <1990Nov13.090732@mathcs.emory.edu>
Organization: The Portal System (TM)
Lines: 62

km@mathcs.emory.edu (Ken Mandelberg) in <1990Nov13.090732@mathcs.emory.edu>
writes:

	This is an expansion on a problem I posted earlier about curses screen
	update optimization. The issue concerns how clever curses is in
	updating a screen to a new screen whoose contents are vertically
	displaced one line. What I notice is that almost all versions of
	curses don't notice the relationshsip between the screens, and repaint
	everything. One version of curses does notice the relationship, and
	updates the screen using scrolling.
	...

His included sample program clearly illustrates the "problem" he laments.

If you drop your baud down to 2400 or 1200 so you can see precisely what it is
that IS being redrawn with the "other" curses, you'll notice that it is NOT
the entire screen being refreshed but only the portion of each line AFTER the
text "This is an ".

Yes, the SVR3.0 version of curses (as I verified) performs an optimization
that does not exist in other versions, but without access to the libcurses'
source I cannot explain why the change.

However, after carefully reading ALL available docs and running numerous
test cases (we're having a curses discussion over in the unix-pc.* newsgroups
right now, and I was the "victor" in a similar dispute at my office just
yesterday) I'm NOT convinced the actions of SVR3.* curses can be considered
a bug since curses DOES refresh ONLY the portions of the physical screen that
changed.

Please note that I agree with you that in the case of ``sc'' the SVR3.0 curses
does a better optimization for that SPECIFIC case, but the other SVR3.* curses
do "good" optimizations for more general situations.

Again, without the source, I can only conjecture that the SVR3.0 curses is
performing "screen cost" optimizations along the lines of GNU emacs whereas
later curses versions appear to solely optimize in accordance with the
published docs (probably for the dual purpose of reduced CPU time and less
memory use).

The algorithms used by GNU emacs are quite effective especially for dial-in
at reduced bauds, and it would be "nice" if they could be optioned-into SVR3+
curses.

But that would be a "Development Request" and not something we're likely to
see anytime soon.  Sigh.

Along these lines, I checked the AT&T ToolChest today (Tuesday) and found
some interesting things there (including ksh-1988e, infocmp and captoinfo), but
I did NOT find ``libcurses'' available as an unbundled product.

Does anyone know if the source(s) to ``libcurses'' with SVR3.* terminfo
support are available from AT&T without requiring a complete UNIX Source
License?  I'm not asking for a "freebee", I'm looking to purchase it for use
with my product which MUST have the same "look and feel" no matter what SysV
system it's on; as I've recently discovered to my dismay, not all vendors'
ports of various SysV or SysV-like systems feature a "modern" curses.  A phone
number or email contact at AT&T would be greatly appreciated.  I'm also
willing to consider any OTHER product that will provide "vt100-style" line
drawing, region scrolling, bold/blink/underline, cursor-key cognizance, etc.

Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]