john@jwt.UUCP (John Temples) (06/12/91)
I've got a couple of curses application which split the screen into two horizontal windows. Both windows display scrolling text. I do a scrollok(TRUE) and idlok(TRUE) on each window. The first problem is the speed of the scrolling -- it's about 25% of the speed of catting a file to the console (if that). Even with a full screen window, the scrolling speed is about the same. Is it just that curses is slow, or is there a better way to do what I want? The second problem occurs when scrolling the upper window in one of these applications. With idlok() enabled, the lower window jumps up and down a line for every line the upper window scrolls. The bottom window becomes a blur while the top window is scrolling. If I turn off idlok(), the unpleasant artifacts disappear, but scrolling speed falls dramatically, while CPU consumption rises. Is there any way to get clean, fast scrolling in two windows like this? -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
tif@doorstop.austin.ibm.com (Paul Chamberlain) (06/12/91)
Not really an answer but some information that might lead you in the right direction. In article <1991Jun11.211657.17798@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >The second problem occurs when scrolling the upper window in one of >these applications. With idlok() enabled, the lower window jumps up >and down a line for every line the upper window scrolls. This is being done by deleting a line at the top of the top window and inserting a blank line at the bottom of the top window. >If I turn off >idlok(), the unpleasant artifacts disappear, but scrolling speed falls >dramatically, while CPU consumption rises. Is there any way to get >clean, fast scrolling in two windows like this? This is done by redrawing each line I think. What you really want is something that uses scroll regions. Now, it'd be convenient if I knew whether curses knows how to use scroll regions or not but I don't. If it does though, all you have to do (I'm guessing now) is make sure that the terminfo entry for your terminal has the right thing for "csr". Also, yeah it'd be nice if curses knew that when scrolling a full screen window all you have to do is new-line from the bottom line. Paul Chamberlain | I do NOT speak for IBM. IBM VNET: PAULCC AT AUSTIN 512/838-9748 | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (06/13/91)
From article <1991Jun11.211657.17798@jwt.UUCP>, by john@jwt.UUCP (John Temples): > scrollok(TRUE) and idlok(TRUE) on each window. The first problem is > the speed of the scrolling -- it's about 25% of the speed of catting a > file to the console (if that). Even with a full screen window, the > scrolling speed is about the same. Is it just that curses is slow, or > is there a better way to do what I want? Curses is widely regarded as "boy, what a dog." I don't know about the truth of such allegations, since I have avoided curses since. You might want to do your own horizontal window management, using the terminfo/termcap libraries directly. However, even then you'll still be slower than a "cat", because you'll have to set up the scrolling regions and re-set the cursor every time you switch to another "window". These codes take up I/O bandwidth. > The second problem occurs when scrolling the upper window in one of > these applications. With idlok() enabled, the lower window jumps up > and down a line for every line the upper window scrolls. The bottom > window becomes a blur while the top window is scrolling. If I turn off > idlok(), the unpleasant artifacts disappear, but scrolling speed falls > dramatically, while CPU consumption rises. Is there any way to get > clean, fast scrolling in two windows like this? This sounds like a problem with either your terminal or your termcap entry. Some terminals, such as TVI's or Lear-Siegler, do not have scrolling-region capability. I.e., the only way they can scroll is to delete a line at the top of the screen, insert a line at the middle of the screen (where the new blank line will be), and thus you get that "jump" effect. Note that this is also slowing down your scrolling considerably, because terminals take a measurable amount of time to move 4K of data memory up, then back down (most terminals are still based upon old 8-bit microprocessors, especially the old ones like you're apparently using). Thus your termcap or terminfo entry will have these commands heavily padded, thus adding a delay. There's three solutions here: upgrade to a new terminal (VT100 compatibles are pretty crufty, but they do have scrolling regions), correct your termcap or terminfo entry in the event that your terminal DOES have scrolling regions, or simply don't scroll -- just re-paint the areas of the screen that have changed. This works okay at 9600 baud or faster speeds, but your dial-up users at 2400 baud will probably curse you. And of course spitting all that data out DOES cause lots of CPU usage... you're re-painting an entire "window" every time you "scroll" a line. Terminals are persnickety critters. Welcome to The Real World (tm) :-). Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg Looking for a job... Unix/C... tips, leads appreciated.
torek@elf.ee.lbl.gov (Chris Torek) (06/19/91)
In article <8398@awdprime.UUCP> tif@doorstop.austin.ibm.com (Paul Chamberlain) writes: >Also, yeah it'd be nice if curses knew that when scrolling a full >screen window all you have to do is new-line from the bottom line. This does not always work, and certainly complicates matters greatly. Terminal manufacturers seem to be able to come up with the most bizarre behaviours. For instance, some terminals distinguish between blanks and `non blank white space'; some retain display text above and below; some use absolute cursor addressing and some screen-relative; and so forth. It may not be impossible, but it is definitely hard, to use newline for up-scrolling. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov