Jonathan Stone <jonathan@DSG.Stanford.EDU> 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.

The point is, the SUNSCRL code can cause the console to scroll between
0 (i think; wrap mode) and the size of the screen at a time, even if
there isn't otherwise reason to do so.

again, the point of trying it is to see what impact scrolling multiple
lines at a time might get you.  i.e. sure it's good, but how good?
and how much extra doesn't even matter?

i.e. is 400 bytes of buffer enough? 800?  1k?


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

"no comment."


> >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)

sure.  the SUNSCRL bits do the 'wrong' thing, and _do_ lose more bits
off the top than they need to.  however, that can be useful behaviour,
e.g. in this case.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.