Xref: utzoo comp.sys.att:10965 comp.unix.questions:27143 unix-pc.general:6565
Path: utzoo!utgpu!watserv1!watmath!uunet!shelby!apple!vsi1!zorch!hico2!kak
From: kak@hico2.UUCP (Kris A. Kugel)
Newsgroups: comp.sys.att,comp.unix.questions,unix-pc.general
Subject: Re: Redraw problem with USG 3.x curses
Summary: sounds like the same termcap was used . . . .
Message-ID: <378@hico2.UUCP>
Date: 26 Nov 90 19:40:45 GMT
References: <6476@emory.mathcs.emory.edu> <35532@cup.portal.com>
Followup-To: comp.sys.att,comp.unix.questions,unix-pc.general
Organization: High Country Software
Lines: 31

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