[mosh-users] Thoughts on scrolling

[Peter Jeremy]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/mosh-users/attachments/20120425/d3c1cb77/attachment.bin