jr@bbn.com (John Robinson) (03/17/89)
In article <12698@pearl.BBN.COM>, milazzo@bbn (Paul Milazzo) writes: >In article <36764@bbn.COM> ellard@vax.bbn.com (Dan Ellard) writes: >> >> I've noticed that when I am logged into a SUN through my BitGraph >>vi takes a loooonnng time to scroll a new line onto the screen. A control-D >>(scroll half a screen down) takes thirty seconds to complete! > >The bg termcap entry on my SUN specifies massive amounts of padding; the >sf (scroll forwards) capability gives 280 ms of padding, or almost 18 >seconds for 64 lines. I don't think the BitGraph is THAT slow... > >See whether reducing the amount of padding speeds things up. The termcaps that have that bogosity were constructed when the Bitgraph had really Really dumb bitblit software, and took a verrrrry long time to scroll. Also, the scroll would take several refreshes, and since the raster is vertical (!), you'd get this sort of queasy, swimming effect watching it. The intent of the termcap was to encourage editors that used it *never* to scroll the screen. Reducing the padding should improve things muchly. Another problem may be that your terminal "speed", as indicated by stty, may be wrong for you actual serial line. This happens, for example, over telnet and rlogin connetions. Since these connections have no true "speed", you can safely issue an stty call to tell the remote machine your actual line speed to the bitgraph. A higher speed will generate extra padding proportional to the bitrate for things like scrolling. If this still doesn't improve things, post your termcap here and we'll see if we can turbocharge it. Also, maybe you should indicate the prom version number (what it tells you when you power on). Contact me by email if you'd rather not air this stuff. /jr jr@bbn.com or bbn!jr C'mon big money!