We've had support for unix sockets for a while now. Make sure this
is reflected in the -help output and the man page.
Also make some minor tweaks to the section to get everything in
sync with reality.
The streams depend on the session and can crash the program if they
are removed in the wrong order. Do a general cleanup of the life time
management of the streams.
Most layouts on Unix generate Meta for Shift+Alt but non-Unix clients
will send XK_Alt_*. This results in us picking some other key which
can confuse some applications.
Try to detect this scenario and map XK_Alt_* to XK_Meta_*.
If we are still in slow start then we haven't discovered the actual
bandwidth limit yet. We also rely on the caller causing a bit of
congestion to detect the limit. So report a higher bandwidth estimate
than what we've currently tested in this scenario.
Loosen the definition of "lossless" a bit so that we can use high
quality JPEG to refresh damaged parts of the screen. Although this
isn't bit perfect, it is close enough that most users will not be
able to tell the difference.
Level 9 is used rather than level 8 because some monitors have
exaggerated contrast that allows the artefacts from level 8 to be
noticeable.
If we have plenty of bandwidth then CPU might be the limiting resource.
Unfortunately we don't have a good number for that limit, so add a
conservative hard coded value.
If an area recently changed then we can guess that it will most likely
change again very soon. In such a case it is meaningless to send a
lossless refresh as it will directly be overwritten. Keep track of
such areas and avoid refreshing them until we no longer see any
changes to them.
We get a whole bunch of very tiny areas, which is very inefficient to
deal with. Instead create a rectangle around every "list" of connected
glyphs (usually each line).
There are some cases where the server state will not automatically
be updated on a change. A prominent one is when only RFB attributes
were changes (e.g. the screen ID) but nothing else. In that case
there is no actual change in the X server, so it never sends any
notification about change back to us.
Ensure queueMutex is always correctly released by using finally blocks. This is the closest approximation of AutoMutex style automatic release you can get in Java.
For KDE we can sometimes get a bunch of stray FL_LEAVE events before
gaining focus. Sending their included button information gets things
in the incorrect order with regard to other synchronisation we do on
focus. So just ignore buttons as the only information we want out of
the leave information is a position update.