From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSYej-0000VW-AE for qemu-devel@nongnu.org; Thu, 29 Jan 2009 10:18:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSYei-0000Uc-Gc for qemu-devel@nongnu.org; Thu, 29 Jan 2009 10:18:12 -0500 Received: from [199.232.76.173] (port=51949 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSYei-0000UP-6I for qemu-devel@nongnu.org; Thu, 29 Jan 2009 10:18:12 -0500 Received: from mail-qy0-f20.google.com ([209.85.221.20]:62856) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSYeh-00007l-J7 for qemu-devel@nongnu.org; Thu, 29 Jan 2009 10:18:11 -0500 Received: by qyk13 with SMTP id 13so12440128qyk.10 for ; Thu, 29 Jan 2009 07:18:10 -0800 (PST) Message-ID: <4981C8A2.8070405@codemonkey.ws> Date: Thu, 29 Jan 2009 09:17:54 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1233228298-4844-1-git-send-email-agraf@suse.de> <1233228298-4844-2-git-send-email-agraf@suse.de> <1233228298-4844-3-git-send-email-agraf@suse.de> <1233228298-4844-4-git-send-email-agraf@suse.de> <1233228298-4844-5-git-send-email-agraf@suse.de> <1233228298-4844-6-git-send-email-agraf@suse.de> <1233228298-4844-7-git-send-email-agraf@suse.de> <1233228298-4844-8-git-send-email-agraf@suse.de> In-Reply-To: <1233228298-4844-8-git-send-email-agraf@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 7/7] Add tight encoding (jpeg) to vnc.c Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org Alexander Graf wrote: > Because we can now speak the tight protocol, let's use it to > transmit jpeg data to the client! > > This patch adds a really easy implementation of the jpeg tight > encoding. Tight in general can do a lot more, but let's take small > steps here and see how things perform. > > Signed-off-by: Alexander Graf > I don't really like the idea of taking this. Tight is supported by a lot of clients and is usually very high on the preferred list. However, most servers do not enable jpeg compression by default because it's lossy. 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. Regards, Anthony Liguori