The following artifical test (just the bitmap operation part) running
vnc_update_client 65536 times on a 2560x2048 surface illustrates the
performance difference:
All bits clean - vnc_update_client_new: 0.07 secs
vnc_update_client_new2: 0.07 secs
vnc_update_client_old: 10.98 secs
All bits dirty - vnc_update_client_new: 11.26 secs
- vnc_update_client_new2: 0.29 secs
vnc_update_client_old: 20.19 secs
Few bits dirty - vnc_update_client_new: 0.07 secs
- vnc_update_client_new2: 0.07 secs
vnc_update_client_old: 10.98 secs
vnc_update_client_new2 shows the performance of vnc_update_client
with this patch added.
Comparing with the test run of the last patch the performance
is at least unchanged while it is significantly improved
for the all bits dirty case.
Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
vnc_update_client currently scans the dirty bitmap of each client
bitwise which is a very costly operation if only few bits are dirty.
vnc_refresh_server_surface does almost the same.
this patch optimizes both by utilizing the heavily optimized
function find_next_bit to find the offset of the next dirty
bit in the dirty bitmaps.
The following artifical test (just the bitmap operation part) running
vnc_update_client 65536 times on a 2560x2048 surface illustrates the
performance difference:
All bits clean - vnc_update_client_new: 0.07 secs
vnc_update_client_old: 10.98 secs
All bits dirty - vnc_update_client_new: 11.26 secs
vnc_update_client_old: 20.19 secs
Few bits dirty - vnc_update_client_new: 0.08 secs
vnc_update_client_old: 10.98 secs
The case for all bits dirty is still rather slow, this
is due to the implementation of find_and_clear_dirty_height.
This will be addresses in a separate patch.
Signed-off-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
this allows for setting VNC_DIRTY_PIXELS_PER_BIT to different
values than 16 if desired.
Reviewed-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Spotted by Coverity:
876 static int vnc_update_client_sync(VncState *vs, int has_dirty)
877 {
(1) Event freed_arg: "vnc_update_client(VncState *, int)" frees "vs". [details]
Also see events: [deref_arg]
878 int ret = vnc_update_client(vs, has_dirty);
(2) Event deref_arg: Calling "vnc_jobs_join(VncState *)" dereferences freed pointer "vs". [details]
Also see events: [freed_arg]
879 vnc_jobs_join(vs);
880 return ret;
881 }
Remove vnc_update_client_sync wrapper, replace it with an additional
argument to vnc_update_client, so we can so the sync properly in
vnc_update_client (i.e. skip it in case of a client disconnect).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Hi,
When I use RealVNC viewer client (http://www.realvnc.com/) to connect vnc server,
the client disconnect suddenly, and I click reconnect button immediately, then the Qemu crashed.
In the function vnc_worker_thread_loop, will call vnc_async_encoding_start
to set the local vs->output buffer by global queue's buffer. Then send rectangles to
the vnc client call function vnc_send_framebuffer_update. Finally, Under normal circumstances,
call vnc_async_encoding_end to set the global queue'buffer by the local vs->output conversely.
When the vnc client disconnect, the job->vs->csock will be set to -1. And the current prcoess
logic will goto disconnected partion without call function vnc_async_encoding_end.
But, the function vnc_send_framebuffer_update will call buffer_reserve, which
maybe call g_realloc reset the local vs's buffer, meaning the global queue's buffer is modified also.
If anyone use the original global queue's buffer memory will cause corruption and then crash qemu.
This patch assure the function vnc_async_encoding_end being called
even though the vnc client disconnect suddenly.
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
VncTight member uint8_t quality is either (uint8_t)-1 for lossless or
less than 10 for lossy.
tight_detect_smooth_image() first promotes it to int, then compares
with -1. Always unequal, so we always execute the lossy code. Reads
beyond tight_conf[] and returns crap when quality is actually
lossless.
Compare to (uint8_t)-1 instead, like we do elsewhere.
Spotted by Coverity.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
If enabled, set the thread name at creation (on GNU systems with
pthread_set_np)
Fix up all the callers with a thread name
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
I've ported the SDL1.2 code over, and rewritten it to use the SDL2 interface.
The biggest changes were in the input handling, where SDL2 has done a major
overhaul, and I've had to include a generated translation file to get from
SDL2 codes back to qemu compatible ones. I'm still not sure how the keyboard
layout code works in qemu, so there may be further work if someone can point
me a test case that works with SDL1.2 and doesn't with SDL2.
Some SDL env vars we used to set are no longer used by SDL2,
Windows, OSX support is untested,
I don't think we can link to SDL1.2 and SDL2 at the same time, so I felt
using --with-sdlabi=2.0 to select the new code should be fine, like how
gtk does it.
v1.1: fix keys in text console
v1.2: fix shutdown, cleanups a bit of code, support ARGB cursor
v2.0: merge the SDL multihead patch into this, g_new the number of consoles
needed, wrap DCL inside per-console structure.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes & improvements by kraxel:
* baum build fix
* remove text console logic
* adapt to new input core
* codestyle fixups
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This removes the last user of the lecagy input mouse handler list,
so we can remove more legacy bits with this.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
legacy mouse event handlers are registered in the new core,
so they receive events submitted to the new input core.
legacy kbd_mouse_event() continues to use the old code paths.
So new-core event handlers wouldn't see events submitted via
kbd_mouse_event.
This leads to the constrain that we we must transition all
kbd_mouse_event() users first to keep things working. But
that is easier to handle than translating legacy mouse events
into new-core mouse events ;)
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Transform absolute mouse events according to graphic_rotate.
Legacy input code does it for both absolute and relative events,
but the logic is broken for relative coordinates, so this is
most likely not used anyway.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Likewise a bunch of helper functions to manage mouse button
and movement events, again to make life easier for the ui code.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
legacy kbd event handlers are registered in the new core,
so they receive events from the new input core code.
keycode -> scancode translation needed here.
legacy kbd_put_keycode() sends events to the new core.
scancode -> keycode translation needed here.
So with this patch the new input core is fully functional
for keyboard events. New + legacy interfaces can be mixed
in any way.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
A bunch of helper functions to manage keyboard events,
to make life simpler for the ui code when submitting
keyboard events.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
