Subject: Re: More on rcons performance woes: pmax profiling
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Chris G. Demetriou <email@example.com>
Date: 03/02/1999 17:27:10
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 ;)
> >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.
Chris Demetriou - firstname.lastname@example.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.