Re: [Qemu-devel] Sensible VNC encodings

[Anthony Liguori <anthony@codemonkey.ws>]

Johannes Schindelin wrote:
> Hi,
>
> On Wed, 21 May 2008, Anthony Liguori wrote:
>
>   
>> Johannes Schindelin wrote:
>>
>>     
>>> On Tue, 20 May 2008, Anthony Liguori wrote:
>>>
>>> Clearly, you have never waited one minute for a full screen update 
>>> from a machine half around the planet.
>>>
>>> That is what happens here with hextile + an compressed SSH tunnel, 
>>> just in case you thought this was pure speculation.
>>>
>>> It is pretty obvious why, too: generic compression, such as SSH's, 
>>> will never outperform specialized compression, such as tight 
>>> compression.
>>>       
>> Tight uses zlib compression in combination with a palette mechanism.  
>> Hextile is a palette mechanism so adding zlib compression to it (via 
>> ssh) makes it pretty comparable to Tight.
>>     
>
> I'm awfully short on time, so this is only a hint to the explanation:
>
> Tight compression can fall back to a Jpeg scheme which is lossy.  You 
> obviously did not know that, and obviously this is what I have to use to 
> make VNC usable.
>   

I clearly did seeing that I implemented Tight compression support in 
gtk-vnc.  The jpeg compression is optional and requires the use of 
additional pseudo-encodings to activate it.

I really don't like the idea of using a lossy encoding though.  I think 
you would find that the builtin VNC + compression over SSH does better 
than Tight + jpeg because of the fact that in the builtin VNC server, we 
reduce the size of the update regions before encoding.  libvncserver 
always has to operate at scanline granularities so it's update regions 
are much larger.

Regards,

Anthony Liguori

> Hth,
> Dscho
>
>