mintty slow refresh rate over RDP

[R0b0t1]

On Tue, Nov 27, 2018 at 5:38 PM Brian Inglis
<Brian.Inglis@systematicsw.ab.ca> wrote:
>
> On 2018-11-26 16:34, Thomas Wolff wrote:
> > Am 26.11.2018 um 23:36 schrieb L A Walsh:
> >> On 11/26/2018 12:20 PM, David Dombrowsky wrote:
> >>     I find best results hosting the GUI (the window of
> >> the TTY) on the local machine, and only transfering the data
> >> (the txt of the ssh session).
> >>     On of the features you might want to use for your situation,
> >> though, is make sure "jump-scroll" is turned on if it is not.
> >> Otherwise any terminal program might take a very long time to catch
> >> up.  It really is an expensive operation to scroll text on a remote
> >> machine.  Early HW terminals and PC screens used special hardware
> >> to perform scrolling at fast speed.  Performing a smooth scroll
> >> via bit-moves of memory would be VERY painful on older machines
> >> or current machines using a slow-enough remote interface.
>
> Glass ttys needed special hardware because the early uP chips running at low
> speeds with small ROMs could not do much between displaying lines.
> VT100 smooth scroll with No Scroll key toggle was like having more/less built in
> to the terminal; VT52 had a Scroll key which supported something similar.
>
> > Mintty does not support smooth scrolling. (I gave it a try once but there is no
> > complete implementation.)
>
> Smooth scroll is a screen update after each scan line instead of each char line
> so displays about eight times slower than jump scroll.
>
> >>     Try running xterm locally and make sure TERM is set correctly on the
> >> remote machine and I think you may be happier
> >> with the performance and "feel"...
>
> Connect using ssh (-Y or with appropriate session settings in ~/.ssh/config) to
> Windows/Cygwin bash from your Linux console/term/tmux/screen session like you
> would to any other Unix system.
>

While this workaround may work here, all current (2018Q4) SSH
implementations do not implement Window's permission model properly
and may not ever do so. Microsoft has their own port of OpenSSH and is
having trouble doing this. There are some programs that will not run
under SSH as it exists now, or even as packaged by Bitvise.

> > A good suggestion anyway.
> > However, if you provide instructions on how to reproduce the issue, I may find
> > time to check out whether there is some improvement potential.
>
> Sounds like the issue is sending images of fast scrolling text over early RDP
> protocol sessions which can probably only be improved by not updating the screen
> as much when running under a remote session using an early protocol.
> Perhaps more recent RDP protocol sessions recognized and transmitted the text
> updates rather than image updates, less frequent image updates, or used some
> terminal display optimizations developed over the decades since glass ttys were
> replaced by term emulators.
>

More recent RDP sessions should fix this. They do not send GDI calls
and instead capture the screen at intervals and compress it. There
should be no traffic generated by frequent screen updates.

Cheers,
    R0b0t1

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple