[mosh-users] Thoughts on scrolling

[Keith Winstein]

We have a prototype design sketched out at 
https://github.com/keithw/mosh/issues/2 that I think addresses most of 
these concerns.

The plan is for the (scrolling) UI to be on the client side, but the 
scrollback is stored on the server side and demand-paged line-by-line to 
the client (which can prefetch if it wants to, and will already have most 
of the lines from when they were on the screen). When the user is 
scrolling back, we will show "missing" lines somehow distinctively (like a 
yellow blank line going across the screen) until the data are filled in by 
the server.

We should be able to support the mouse wheel, etc. I'm not sure about 
PgUp, PgDown without modifiers. (We will only grab these when the inner 
terminal is not in the alternate screen.)

On Wed, 25 Apr 2012, Peter Jeremy wrote:

> On 2012-Apr-24 11:20:07 -0400, Scott Gifford <sgifford at suspectclass.com> wrote:
>> It's not really the speed of data transfer that makes tmux/screen scrolling
>> a hassle, it's the slowness of the interface.  I wonder if a history API
>> consisting of terminal escape sequences for up-n-lines, down-n-lines,
>> goto-line-n, and search-history would be enough for a full-fledged GUI
>> terminal to integrate into the history mechanism, including scrollbars?
>
> That might be useful but you would need to get buy-in from the more
> popular terminal emulators.
>
>>> The other option is for mosh to track the full size of the terminal's
>>> scrollback buffer, rather than just the visible screen,
>>
>> That seems simpler than implementing a history API.  Without knowing the
>> internal data structures of mosh, my intuition is that the data
>> requirements would be modest.  For example, I have a 1000-line scrollback
>> buffer with an 80-character wide terminal, so if historical lines were kept
>> in a circular buffer my configuration would require around 80KB.
>
> Actually, mosh stores about 40 bytes per character, not 1, so your
> 1000x80 example represents about 3.2MB, not 80KB.  If you re-worked
> Terminal::Cell to minimise space requirements, you might be able to
> get it down to 8 but you need to store a wide character and attributes
> at each cell, not just a char.
>
>>  If the client is online most of that data would be sent anyways;
>
> Assuming a LAN.  If you were generating a decent volume of data and
> monitoring it over a lossy and high-RTT 3G network, I suspect the
> lost data would be hgiher.
>
>> if the client is
>> offline it would be possible to store it on disk until it came back online
>> if server memory consumption were an issue.
>
> There's also the issue of transferring the additional state to the client.
>
>>  If I take 1000 lines of
>> find(1) output (a typical case for a scrollback buffer), it is about 60KB
>> of data, and compresses to 8.5KB, so in the case of a client that has been
>> offline for awhile, compression may be able to reduce the data transfer a
>> great deal.
>
> Except that mosh compresses each transmitted Instruction (see the paper)
> independently, so the compression ratio is unlikely to exceed 2:1.
>
> Anyway, feel free to knock up a proof of concept...
>
> -- 
> Peter Jeremy
>