Avoid direct access to the screen dimensions and layout so that we
can make sure it stays sane. This also makes sure the layout is
properly updated when we only get the screen dimensions from the
server.
This makes VNCServer a sufficiently complete interface that callers
don't need to know about the specific implementation (VNCServerST
currently). And assuming that all servers will use sockets is not
that outrageous.
Removed the last parts of VNCSConnectionST's back door in to
VNCServerST and let the parent class fully handle coordination of
clients, and access to the desktop.
There is some client coordination needed which is better encapsulated
inside VNCServerST. This also helps hiding the desktop from the
individual clients.
Force queryConnection() to always call back to approveConnection()
rather than return special values. This makes the flow easier to
follow as it will be the same in all cases.
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.
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.
The system to avoid processing changes for a stopped desktop was a
bit overly aggressive and resulted in those changes getting stuck even
when the desktop started again (yet another change was needed to get
things rolling again).
Make sure we flush out anything pending once the desktop is back up and
running. We don't use the frame timer here as we no longer know how
old these changes are, so we're not really rate limiting any application.
Comparing ScreenSet:s should be done without considering order
Avoids that a viewer connected to Xvnc sometimes disconnects with
"Desktop configured a different screen layout than requested" when
screens are changing.