Anthony Liguori wrote:
If we implement Tight and then use jpeg by default, for most clients,
the default is going to be lossy encoding. While lossy isn't so bad for
high detailed images (like pictures), it's pretty terrible for simple,
high contrast images (like windows in a desktop).
TightVNC has some sophisticated heuristics for determining whether to
use jpeg or not (when it's enabled). I think that sort of heuristic is
a prerequisite for enabling tight's jpeg support.
FWIW, Tight essentially does hextile encoding but adds zlib
compression. That's probably a better place to start as it should
outperform hextile while remaining lossless.
Another thing to consider is that using jpeg compression is going to
worsen qemu performances, so I think it should be used only when
necessary, e.g. the network connection between client and server is bad.