From 0780ec7be82dd4781e9fd216b5d99a125882ff5a Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Tue, 21 Jan 2020 07:02:10 +0100 Subject: [PATCH 1/3] Revert "vnc: allow fall back to RAW encoding" This reverts commit de3f7de7f4e257ce44cdabb90f5f17ee99624557. Remove VNC optimization to reencode framebuffer update as raw if it's smaller than the default encoding. QEMU's implementation was naive and didn't account for the ZLIB z_stream mutating with each compression. Because of the mutation, simply resetting the output buffer's offset wasn't sufficient to "rewind" the operation. The mutated z_stream would generate future zlib blocks which referred to symbols in past blocks which weren't sent. This would lead to artifacting. Considering that ZRLE is never larger than raw and even though ZLIB can occasionally be fractionally larger than raw, the overhead of implementing this optimization correctly isn't worth it. Signed-off-by: Cameron Esfahani Signed-off-by: Gerd Hoffmann --- ui/vnc.c | 20 ++------------------ 1 file changed, 2 insertions(+), 18 deletions(-) diff --git a/ui/vnc.c b/ui/vnc.c index 4100d6e404..3e8d1f1207 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -898,8 +898,6 @@ int vnc_raw_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) int vnc_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) { int n = 0; - bool encode_raw = false; - size_t saved_offs = vs->output.offset; switch(vs->vnc_encoding) { case VNC_ENCODING_ZLIB: @@ -922,24 +920,10 @@ int vnc_send_framebuffer_update(VncState *vs, int x, int y, int w, int h) n = vnc_zywrle_send_framebuffer_update(vs, x, y, w, h); break; default: - encode_raw = true; + vnc_framebuffer_update(vs, x, y, w, h, VNC_ENCODING_RAW); + n = vnc_raw_send_framebuffer_update(vs, x, y, w, h); break; } - - /* If the client has the same pixel format as our internal buffer and - * a RAW encoding would need less space fall back to RAW encoding to - * save bandwidth and processing power in the client. */ - if (!encode_raw && vs->write_pixels == vnc_write_pixels_copy && - 12 + h * w * VNC_SERVER_FB_BYTES <= (vs->output.offset - saved_offs)) { - vs->output.offset = saved_offs; - encode_raw = true; - } - - if (encode_raw) { - vnc_framebuffer_update(vs, x, y, w, h, VNC_ENCODING_RAW); - n = vnc_raw_send_framebuffer_update(vs, x, y, w, h); - } - return n; } From 557ba0e57200014bd4f453f6516f02b61bdfc782 Mon Sep 17 00:00:00 2001 From: Cameron Esfahani Date: Mon, 20 Jan 2020 21:00:52 -0800 Subject: [PATCH 2/3] vnc: prioritize ZRLE compression over ZLIB In my investigation, ZRLE always compresses better than ZLIB so prioritize ZRLE over ZLIB, even if the client hints that ZLIB is preferred. zlib buffer is always reset in zrle_compress_data(), so using offset to calculate next_out and avail_out is useless. Signed-off-by: Cameron Esfahani Message-Id: Signed-off-by: Gerd Hoffmann --- ui/vnc-enc-zrle.c | 4 ++-- ui/vnc.c | 11 +++++++++-- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/ui/vnc-enc-zrle.c b/ui/vnc-enc-zrle.c index 17fd28a2e2..b4f71e32cf 100644 --- a/ui/vnc-enc-zrle.c +++ b/ui/vnc-enc-zrle.c @@ -98,8 +98,8 @@ static int zrle_compress_data(VncState *vs, int level) /* set pointers */ zstream->next_in = vs->zrle->zrle.buffer; zstream->avail_in = vs->zrle->zrle.offset; - zstream->next_out = vs->zrle->zlib.buffer + vs->zrle->zlib.offset; - zstream->avail_out = vs->zrle->zlib.capacity - vs->zrle->zlib.offset; + zstream->next_out = vs->zrle->zlib.buffer; + zstream->avail_out = vs->zrle->zlib.capacity; zstream->data_type = Z_BINARY; /* start encoding */ diff --git a/ui/vnc.c b/ui/vnc.c index 3e8d1f1207..1d7138a3a0 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -2071,8 +2071,15 @@ static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings) break; #endif case VNC_ENCODING_ZLIB: - vs->features |= VNC_FEATURE_ZLIB_MASK; - vs->vnc_encoding = enc; + /* + * VNC_ENCODING_ZRLE compresses better than VNC_ENCODING_ZLIB. + * So prioritize ZRLE, even if the client hints that it prefers + * ZLIB. + */ + if ((vs->features & VNC_FEATURE_ZRLE_MASK) == 0) { + vs->features |= VNC_FEATURE_ZLIB_MASK; + vs->vnc_encoding = enc; + } break; case VNC_ENCODING_ZRLE: vs->features |= VNC_FEATURE_ZRLE_MASK; From a1e8853ed2acbda29a52533abc91b035b723952e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Date: Mon, 20 Jan 2020 20:29:47 +0100 Subject: [PATCH 3/3] ui/console: Display the 'none' backend in '-display help' MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Commit c388f408b5 added the possibility to list the display backends using '-display help'. Since the 'none' backend is is not implemented as a DisplayChangeListenerOps, it is not registered to the dpys[] array with qemu_display_register(), and is not listed in the help output. This might be confusing, as we list it in the man page: -display type Select type of display to use. This option is a replacement for the old style -sdl/-curses/... options. Valid values for type are none Do not display video output. The guest will still see an emulated graphics card, but its output will not be displayed to the QEMU user. This option differs from the -nographic option in that it only affects what is done with video output; -nographic also changes the destination of the serial and parallel port data. Fix by manually listing the special 'none' backend in the help. Suggested-by: Thomas Huth Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Eric Blake Message-id: 20200120192947.31613-1-philmd@redhat.com Signed-off-by: Gerd Hoffmann --- ui/console.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ui/console.c b/ui/console.c index 69339b028b..179901c35e 100644 --- a/ui/console.c +++ b/ui/console.c @@ -2338,6 +2338,7 @@ void qemu_display_help(void) int idx; printf("Available display backend types:\n"); + printf("none\n"); for (idx = DISPLAY_TYPE_NONE; idx < DISPLAY_TYPE__MAX; idx++) { if (!dpys[idx]) { ui_module_load_one(DisplayType_str(idx));