Less Optimized Curses

Ken Mandelberg km at mathcs.emory.edu
Wed Nov 14 01:07:32 AEST 1990


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 at mathcs.emory.edu          PREFERRED
Emory University    | {rutgers,gatech}!emory!km    UUCP 
Dept of Math and CS | km at emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963



More information about the Comp.sys.att mailing list