Subject: Re: More on rcons performance woes: pmax profiling
To: Chris G. Demetriou <cgd@netbsd.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 03/02/1999 16:24:57
In message <8790dflafu.fsf@redmail.redback.com>,
Chris G. Demetriou writes:

>> Sure, execpt that wont have much effect, unless we also widen the path
>> which Bill Sommerfeld fixed last month.
>
>False.  if the main cost is, in fact, the scrolling, then scolling
>multiple lines at once via SUNSCRL (in the sun emulation, of course)
>should definitely show an effect, even without any other changes.

but I dont think the performance impact of scrolling ~2 lines at a
time, (or whatever the 128-byte limit on strings wscons hands down to
the blit code comes to) rather than 1, is particuarly interesting.

There's no call to be obnoxious about it, particularly when you're
not even right ;)



>False.  Sun, not "Sun PROM."

But i neither want nor care for complete sun emulation.  On non-sun
hardware, it strikes me as inane. I never even called it "sun"
emulation: the termcap entry I use says "rcons". Think "termcap" and
"keypads" and "install software", OK?

>Note that buffering input has nothing to do with the size of the units
>in which you scroll when you do scroll.  it's quite possible to buffer
>input in a way that's compatible (or at least 'effectively compatible)
>with the sun console emulation.

If the code can never see further ahead than N lines worth of
displayed text, then it can never jump-scroll more than N lines at a
time (at least not without risking losing text)