km@mathcs.emory.edu (Ken Mandelberg) (11/13/90)
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.
I don't know how to officially describe the versions of libcurses.a except
to say that the version that comes with SYSVR3.0 does the scrolling, while
the version with SYSVR3.1, SYSVR3.2, SYSVR2.1, and every BSD version I
tried repaints. I did the SYSV experiments on a 3B2 running SYSVR3.2,
linking the same .o file against various versions of libcurses.a. In all
cases I used exactly the same terminfo entry (vt100). In fact the choice
of terminal (and terminfo entry) is not relevant, I tried various
combinations of terminals and entries (sun, xterm, 4425) all with the
same results.
I'm going to include a tiny sample program that exhibits the behavior. With
the 3.0 libcurses this will paint the screen once and do each refresh() as
a physical scroll and a one line update. On all other versions the cursor
will move over every position on the screen updating every cell. On a work
station with very fast screen updates, you may not easily see the difference.
Over a serial line on a terminal (even at 9600 baud) the difference is very
obvious.
The 3B2 is the only machine I have a full set of libcurses.a binaries for.
I've also tried this on SunOS 4.1 which runs both BSD and SYSVR3.1 curses
and do full screen updates. A/UX 1.1 and 2.0 both run some flavor of SYSVR2.X
curses and do full screen updates. The last release of the AT&T 3B1 unix has
SYSVR3.0 derived curses routines and uses scrolling.
I report this partially because I am curious as to why libcurses got less
optimized in recent versions. Perhaps the idea is that on the average it was
not worth looking for automatic scroll optimization, and programs that know
they are scrolling should do it themselves. On the practical side, I would
like an old program that works well on 3.0 to work well on our later systems
without a rewrite (sc the spreedsheet program).
Here is the tiny test program:
#include <curses.h>
#define ODDLINE "This is an odd line
111111111111111111111111111111111111111111"
#define EVENLINE "This is an even line
000000000000000000000000000000000000000000"
main() {
int i,j;
initscr();
for (j=0;j<LINES-1;j++){
for (i=0;i<LINES-1;i++) {
if ((i+j)%2) mvaddstr(i,0,EVENLINE);
else mvaddstr(i,0,ODDLINE);
}
refresh();
}
sleep(10);
endwin();
}
--
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {rutgers,gatech}!emory!km UUCP
Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: (404) 727-7963thad@cup.portal.com (Thad P Floryan) (11/14/90)
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 ]staceyc@sco.COM (Stacey Campbell) (11/15/90)
In article <1990Nov13.090732@mathcs.emory.edu> km@mathcs.emory.edu (Ken Mandelberg) 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. Most modern versions of curses will not use insert line or delete line to achieve scrolling unless they are explicitly requested to do so by the application. You will find that adding; idlok(stdscr, TRUE); directly after the initscr() call will then permit System V 3.2 curses to scroll using insert line/delete line. Here's what the AT&T manual says (somewhat abridged); idlok(win, bf) If enabled, curses will consider using the hardware "insert/delete-line" feature of terminals so equipped. If disabled, curses will very seldom use this feature [I have never seen it use this feature when disabled - Stacey]. It is disabled by default because "insert/delete-line" tends to be visually annoying when used in applications where it isn't really needed. I agree with the manual writer, forcing scrolls in some situations is very irritating to the eye. It is definitely something that should be only used when required. >I report this partially because I am curious as to why libcurses got less >optimized in recent versions. It's not less optimised. The opposite is in fact true. It's only in recent versions (System V 3.1 (?)) for example that typeahead checking has been implemented. >On the practical side, I would >like an old program that works well on 3.0 to work well on our later systems >without a rewrite (sc the spreedsheet program). No need to rewrite. One of the first things I did to sc when I finally got it compiled and running was to add the line idlok(stdscr, TRUE) in sc.c. -- Stacey Campbell staceyc@sco.com {uunet,decwrl,ucscc,att,sq,altos,lotus,phoenix,sun,microsoft,xbs}!sco!staceyc