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-7963weave@brahms.udel.edu (Ken Weaverling) (11/14/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. > I have a SYS V 3.1 box and below is a portion of the man page for curses... It's warning about being "visually annoying" should be heeded. I used idlok() in a program I write and users complained so much that I had to make a command line option to allow people to choose what method is used. idlok(win, bf) If enabled (bf is TRUE), curses will consider using the hardware ``insert/delete-line'' feature of termi- nals so equipped. If disabled (bf is FALSE), curses will very seldom use this feature. (The ``insert/delete- character'' feature is always considered.) This option should be enabled only if your application needs ``insert/delete-line'', for example, for a screen editor. It is disabled by default because ``insert/delete-line'' tends to be visually annoying when used in applications where it isn't really needed. If ``insert/delete-line'' can- not be used, curses will redraw the changed portions of all lines. Not cal- ling idlok() saves approximately 5000 bytes of memory. -- Ken Weaverling (insert any job title here, except for official spokesperson) Delaware Technical & Community College --- weave@brahms.udel.edu
kpv@ulysses.att.com (Phong Vo[drew]) (11/14/90)
In article <1990Nov13.090732@mathcs.emory.edu>, km@mathcs.emory.edu (Ken Mandelberg) writes:
: 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,
No version of BSD curses knows how use insert/delete lines for screen update
so there can be no scrolling using BSD curses. All sysV versions know how to
do this though via different algorithms. SysVr2.1 and SysV3.0 use an algorithm
based on Heckel's file differencing technique. SysVr3.1 and SysVr3.2
use an algorithm that I developed based on a string comparison
problem that I call the minimum-distance longest common subsequence problem.
: 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 error in your program is that you did not declare stdscr to be a window
on which insert/delete lines can be used. This is done via the call
idlok(stdscr,TRUE);
I believe that the reason for requiring idlok() was because, contrary to
one's intuition, many people dislike the use of insert/delete lines.
It can be very distracting when the screen jumps up and down.
The minimum-distance longest common subsequence problem was invented to
alleviate this problem. Even then, there are still cases when the screen
jumps too much.
: Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Phong Vo, att!ulysses!kpvggw%wolves@cs.duke.edu (Gregory G. Woodbury) (11/14/90)
Actually, I THINK that the difference can simply be one of whether or not the curses package comes with one logical switch enabled or disabled by default. There are two logicals [idlok and scrollok] that control the logical use of insert/delete line and window scrolling. I can easily imagine that a simple difference between the default setting of these options could cause the visual effect that you are noticing. Just another curses user. -- Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC UUCP: ...dukcds!wolves!ggw ...mcnc!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ] <standard disclaimers apply>
thad@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
torkel@bibsyst.UUCP (Torkel Hasle) (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. > If you add the following line after initscr(), curses will use hardware scrolling: idlok(stdscr,TRUE); This is documented in the SVID issue 2. Your example ran with hardware scrolling on my machine (SVR3.1) when I added this line. +----------------------------------------------------------------------+ ! Torkel Hasle, Bibliotek-Systemer A/S, N-3250 Larvik, Norway ! ! uucp: ...nuug!bibsyst!torkel Tel: +47 34 82 202 ! ! torkel@bibsyst.uucp Fax: +47 34 85 185 ! +----------------------------------------------------------------------+
akcs.dgy@vpnet.chi.il.us (Donald Yuniskis) (11/21/90)
>In my former company we dealt with Aspen Scientific. Unfortunately I >don't have their phone number handy, nor their whereabouts, but most Wheatridge, CO (303) 423-8088 >Basically their curses, based on curses from SVR3.2 (with color) is >99.9% if not 100% compatible with AT&T curses. It runs on everything >from DOS, UNIX, and VMS. It makes porting curses-based applications >much easier! Yes and no... Best bet is to buy the sources. The PC version is probably the most up-to-date. It'll take a while for you to sort out all the conditional compilation info... There are quite a few bugs in the version I have (5.0 or 5.1) tho' they're pretty helpful (call from a touchtone phone since their voicemail system -- if its in use -- doesn't give you any hooks to leave a message if you can't tone signal!) >They offer some curses-products as well, something called "Formation" which >handled FORMS and other PC-like windowing (pull down windows, icons, >dialog boxes, etc...) This is _definitely_ worth getting even if you're already running someone (ATT) else's "real" curses. Again, buy the source as you may wish to modify the behaviour of the keyboard in dialog boxes, etc. >I'd recommend it -- I have no connection with Aspen at all, just call me a >satisfied developer. Ditto...