In the early days we relied upon the bounded length of a sync channel
to put back pressure on the output from a child command. We're no
longer using that kind of channel, so here's a more deliberate and
measurable rate limiting implementation.
The `ratelimit_output_bytes_per_second` configuration setting defaults
to 2MB/s and constrains the amount of text we send to the escape
sequence parser.
This value was selected based on it being a combination of responsive
to ctrl-c while outputing a lot of data and still generating sleeps
to remain within the constraints.
This does mean that terminal benchmarks that test how quickly you
can dump text to the terminal will hit this artifical upper limit
and are thus not going to be a true measure of performance.
This removes some redundancy and overhead around setting up the
connection (the native_tls crate doesn't provide PEM functions,
despite every deployment I've ever seen only ever using PEM certs),
but more importantly, gives the control needed to make hostname
verification work in a PKI setup with unusual CN values.
Problem scenario was:
* spawn a window
* resize it larger
* spawn a new tab
When working with a mux client tab, the surface size in the new tab
didn't reflect the size of the remote surface, so the rendering was
messed up.
Arrange to know the size up front.
Repeated moves or wheel events are collapsed so that we don't clog up
the queue. The queue size doesn't matter as much as the latency of
processing a large queue. For fast or repeated moves the queue can grow
rather quickly, and with what is currently ~25-50 ms round trip per
entry for a remote session, that is a poor UX.
The latency is not great, and there are more authentication and
authorization features that need to be added, but this shows that
we can connect and talk to a remote muxer.
It's taking a while for https://github.com/jwilm/vte/pull/20 to get
merged, so point to my branch directly while I build out some
tunneled mux protocol escape sequences.
I'll need to fork vte on crates.io if vte doesn't merge the PR
before the next termwiz crate bump.
This do_paint call was added in 8995974124
but I don't think it was intentional; it looks like an accidental commit
of something during debugging.
The intent is that we tick over and paint every tick (~50ms) and this
behavior here was causing us to paint after every input event, which is
undesirable when processing the selection.
refs: https://github.com/wez/wezterm/issues/33
