km@mathcs.emory.edu (Ken Mandelberg) (11/01/90)
We recently had a need to rebuild the binary for a curses based program
(sc as it happens), and found that the recompiled version performed a
lot worse than the old one. Specifically scrolling degenerated to full
screen updates that were slow even at 9600 baud. This is with the
generic vt100 terminfo entry.
A little investigation showed that the behavior was completely
determined by which libcurses.a we linked against. We got the slow
scroll with the 2.1, 3.1, and 3.2 versions of the library, but fast
scroll with 3.0. The "versions" I'm describing are the System V release
the library came with, not the internal library version (so 3.2 means
System V R 3.2).
Anyone know anything about this? The tests were done on a system (3B2)
where we had all the releases mentioned, but we need to move the
program to a system that only has 3.2.
--
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/03/90)
km@mathcs.emory.edu (Ken Mandelberg) in <6476@emory.mathcs.emory.edu> writes:
We recently had a need to rebuild the binary for a curses based program
(sc as it happens), and found that the recompiled version performed a
lot worse than the old one. Specifically scrolling degenerated to full
screen updates that were slow even at 9600 baud. This is with the
generic vt100 terminfo entry.
A little investigation showed that the behavior was completely
determined by which libcurses.a we linked against. We got the slow
scroll with the 2.1, 3.1, and 3.2 versions of the library, but fast
scroll with 3.0. The "versions" I'm describing are the System V release
the library came with, not the internal library version (so 3.2 means
System V R 3.2).
Anyone know anything about this? The tests were done on a system (3B2)
where we had all the releases mentioned, but we need to move the
program to a system that only has 3.2.
'Sfunny, I had exactly the same symptoms (slow full-screen update, etc.) using
Apple's latest A/UX 2.0. Investigation showed the problem (on A/UX) to be due
to ancient termcap and terminfo databases supplied by Apple. I did NOT have
the problem on my 3B1, SVR3.2, CTIX, or other systems.
On the off-chance my solution may help you, I've included (below) the steps
required to fix the problem under A/UX (as I posted to comp.unix.aux); this
was originally in response to someone having problems "coming in" on the Mac
serial ports under A/UX:
``
If you want to come in on the serial ports with terminals such as VT100, DT80,
VT200, or Falco, there are a LOT of other things you have to fix re: terminfo
and termcap databases since the stock distribution (both A/UX 1.* and 2.0) is
crap in these regards. Missing, for example, are infocmp (complementing tic),
and the acsc (among other) strings in terminfo (you'll see what I mean if you
attempt to use EMACS remotely and wonder why you cannot scroll windows :-)
I've been meaning to post a list of things to fix the terminfo, termcap, and
improve curses support, but haven't had the time yet. But, in essence, you
want to replace /etc/termcap with one from, say, ucbvax.berkeley.edu or from
ucbarpa.berkeley.edu, and also decompile all the terminfo database using the
infocmp on a real SV system (R3.*, R4 or even a 3B1), copy those *.ti files to
A/UX, and recompile using tic under A/UX. These changes make a tremendous
capability and performance difference, besides supporting many terminals not
included in the A/UX 2.0 distribution.
Look at the man pages on a SVR3 system to see how to use infocmp; for some
reason, someone went through a lot of trouble to carefully REMOVE all the
references to infocmp in the man pages for terminfo under A/UX and to also
NOT include the infocmp program in the distribution; fortunately, tic does
accompany A/UX 2.0 and has a man page. And, luckily, tic doesn't coredump
when it encounters terminfo capabilties not supported under A/UX 2.0 (it
simply ignores them).
''
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]kak@hico2.UUCP (Kris A. Kugel) (11/27/90)
In article <35532@cup.portal.com>, thad@cup.portal.com (Thad P Floryan) writes: - km@mathcs.emory.edu (Ken Mandelberg) in <6476@emory.mathcs.emory.edu> writes: - - We recently had a need to rebuild the binary for a curses based program - (sc as it happens), and found that the recompiled version performed a - lot worse than the old one. Specifically scrolling degenerated to full - screen updates that were slow even at 9600 baud. This is with the - generic vt100 terminfo entry. - - A little investigation showed that the behavior was completely - determined by which libcurses.a we linked against. We got the slow - scroll with the 2.1, 3.1, and 3.2 versions of the library, but fast - scroll with 3.0. The "versions" I'm describing are the System V release - the library came with, not the internal library version (so 3.2 means - System V R 3.2). - - Anyone know anything about this? The tests were done on a system (3B2) - where we had all the releases mentioned, but we need to move the - program to a system that only has 3.2. - - 'Sfunny, I had exactly the same symptoms (slow full-screen update, etc.) using - Apple's latest A/UX 2.0. Investigation showed the problem (on A/UX) to be due - to ancient termcap and terminfo databases supplied by Apple. I did NOT have - the problem on my 3B1, SVR3.2, CTIX, or other systems. I've seen further discussion on this topic since the original article was posted, and I'm not sure the original point was addressed. It sounds like the difference is entirely what version of the library was in the link, and why the versions of the library after v. 3.0 are slow. Did anybody answer this question directly? -Kris
thad@cup.portal.com (Thad P Floryan) (11/28/90)
kak@hico2.UUCP (Kris A. Kugel) in <378@hico2.UUCP> writes:
I've seen further discussion on this topic since the original
article was posted, and I'm not sure the original point was addressed.
It sounds like the difference is entirely what version of the library
was in the link, and why the versions of the library after
v. 3.0 are slow. Did anybody answer this question directly?
Bits and pieces of cross-postings were appearing in various newsgroups without
regard to the original post by Ken Mandelberg; I found parts in comp.sys.att,
unix-pc.general, comp.unix.questions and comp.unix.programmer.
But, yes, the original question was answered succinctly:
As other posters noted the issue turns out to be "idlok". While Curses
3.+ doesn't redraw characters that are common, it won't take advantage
of a hardware scroll unless it's allowed to use insert line.
With idlok(stdscr, TRUE) added sc works fine even at low speed.
I guess when I first read the curses docs, my eyes "read" ``idlok'' to mean
"idle OK" (you figure) instead of the correct "insert/delete line OK".
Perhaps the new Usenet-admonishment should be: (RTFM)^2
And a whack alongside the head by a dis-interested 3rd party wouldn't hurt,
either; sometimes it's too easy to get in a rut and NOT open one's eyes.
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]