qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Sensible VNC encodings


From: Anthony Liguori
Subject: Re: [Qemu-devel] Sensible VNC encodings
Date: Wed, 21 May 2008 08:36:02 -0500
User-agent: Thunderbird 2.0.0.14 (X11/20080501)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]