You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently only implement fast mode, but it might make sense to also implement smooth (slow) mode.
This mode only affects adding new lines at a slow rate, but - in modern age - we could correlate that feature with smooth scrolling (of new lines to be added), see #145.
One open question I am having is how long the linefeed should wait until resuming terminal I/O processing.
How to implement
One design idea I am having in my mind is, to actually suspend processing for N msecs on received linefeeds, if slow scrolling mode is enabled. This should effectively also suspend reading from the TTY to avoid flooding the internal buffers.
One open question I am having is how long the linefeed should wait until resuming terminal I/O processing.
On the early DEC terminals (VT100, VT220, VT240, and VT340) the smooth scrolling speed was 6 lines per second. The VT340 apparently also had an option in the settings that could adjust the speed (choosing between 3, 6, and 12).
On level 5 terminals (like the VT510, VT520, and VT525) the default smooth scrolling speed was 9 lines per second, but there was also an escape sequence to adjust that to 18 (See DECSSCLS).
I think the choice was largely dictated by the hardware specs. For example, the VT100 had a 60Hz refresh rate with a cell height of 10px, so scrolling one pixel per refresh gives you 60/10 lines per second. For the VT510, you've got 72Hz and a 16px cell height, so scrolling two pixels per refresh gives you 72*2/16 lines per second.
We currently only implement fast mode, but it might make sense to also implement smooth (slow) mode.
This mode only affects adding new lines at a slow rate, but - in modern age - we could correlate that feature with smooth scrolling (of new lines to be added), see #145.
One open question I am having is how long the linefeed should wait until resuming terminal I/O processing.
How to implement
One design idea I am having in my mind is, to actually suspend processing for N msecs on received linefeeds, if slow scrolling mode is enabled. This should effectively also suspend reading from the TTY to avoid flooding the internal buffers.
References
The text was updated successfully, but these errors were encountered: