Lossy rendering when file.write is very slow over ssh?

[grvstick]

Hi, I've been using textual as tooling in my company and so far it has earned its popularity from the fact that the GUI can be run over SSH.

One of the issues that I've seen while running a textual app in very slow network conditions, the rendering becomes really slow(obviously!). I was surprised to see the background task is being kept alive without too much delay. When I ran the pyinstrument profiling, I saw most of the time it is waiting for the queue.put since the writes on the consumer thread was taking too long I assume.
pyinstrument_textual.zip

Is it possible to implement a lossy rendering when the network speed is too slow? If a missed write occurs would it mess up the integrity of the display altogether?

[willmcgugan]

A missed write would likely garble the display, so lossy rendering wouldn't work I'm afraid -- at least not in the way you describe.

However, the amount of data being sent is unlikely to be the issue. The amount of data sent by Textual is already very low, and it will be compressed on the wire.. One way to reduce it would be to set the env var TEXTUAL_REFRESH to something under 60. I'm guessing 20 would be just about usable.

Ultimately, it is more about latency. If it takes much more than 100ms for the data to arrive, then the user experience will start to suffer. And it won't matter wether that's a few bytes, or a full 20K frame.

You might want to compare what happens if you server the app over http with textual serve. In theory it should be much the same, but if textual serve is more usable it might suggest you can tune ssh for better performance.