Should I always add wl_display_sync() before wl_display_dispatch_queue()?

[Zhao, Halley]

For the wl_display_sync, is there possible scenario that:

1.       Frame callback doesn't come yet when it is checked

2.       Frame callback comes immediately after the check

3.       wl_display_dispatch_queue is called and is blocked since there is no event to dispatch on the queue.
Then application is blocked.

So, I still think the padding wl_display_sync is required.


From: Jason Ekstrand [mailto:jason at jlekstrand.net]
Sent: Tuesday, October 29, 2013 11:07 AM
To: Zhao, Halley
Cc: wayland-devel at lists.freedesktop.org; Antognolli, Rafael
Subject: Re: Should I always add wl_display_sync() before wl_display_dispatch_queue()?


On Mon, Oct 28, 2013 at 9:39 PM, Zhao, Halley <halley.zhao at intel.com<mailto:halley.zhao at intel.com>> wrote:
Video player use frame callback on an event queue, sometimes there is synchronization issue.
After looked at other usage of event queue, I found:
In order to avoid blocking by wl_display_dispatch_queue(), a padding callback of wl_display_sync is added on purpose.
Is my understanding correct?
Here is the changes:
https://gitorious.org/halley-test/gstreamer-vaapi/commit/9846c75e7a2bb223900457beffc3384c77cc5075


however, with or without the above change, I found there is still hangs in my player (efl based) :
https://gitorious.org/gst-plugins-vaapi/simple-player/source/87837fc1b4c11d7a33142c7d4fac1225d8973b80:
it seems to be ECore issue during wl_display_dispatch_pending():

The short answer is that you shouldn't have to.  Also, sitting in a round-trip loop is asking for bad performance if the CPU is under load.
If I had to take a guess, I think it's likely that ecore and gstreamer are fighting over the file descriptor.  I don't know the codebase of either, but you have to be careful with handing it back and forth.  In particular, take a look at wl_display_prepare_read:

http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n1078
I hope that's helpful,
--Jason Ekstrand


Rafael:
Do you think it is an ECore issue?

// wl_display_sync callback with wl_display_dispatch_pending()
(gdb) bt
#0  0xb7c4ddd0 in _ecore_wl_input_cb_keyboard_enter () from /lib/libecore_wayland.so.1
#1  0xb6f16666 in ffi_call_SYSV () from /lib/libffi.so.6
#2  0xb6f163eb in ffi_call () from /lib/libffi.so.6
#3  0xb79a9ae5 in wl_closure_invoke () from /lib/libwayland-client.so.0
#4  0xb79a74c2 in dispatch_queue () from /lib/libwayland-client.so.0
#5  0xb79a803e in wl_display_dispatch_queue_pending () from /lib/libwayland-client.so.0
#6  0xb79a8162 in wl_display_dispatch_pending () from /lib/libwayland-client.so.0
#7  0xb3ca72a6 in gst_vaapi_window_wayland_sync (window=0x87d2d50) at gstvaapiwindow_wayland.c:162
#8  gst_vaapi_window_wayland_render (window=0x87d2d50, surface=0xb0a02860, src_rect=0xb017dbd0, dst_rect=0x88bdbe0, flags=0) at gstvaapiwindow_wayland.c:514
#9  0xb3c5a2fb in gst_vaapi_window_put_surface (window=0x87d2d50, surface=surface at entry=0xb0a02860, src_rect=0xb017dbd0, src_rect at entry=0x0, dst_rect=<optimized out>, dst_rect at entry=0x88bdbe0,
    flags=flags at entry=0) at gstvaapiwindow.c:435
#10 0xb3ccc1e1 in gst_vaapisink_put_surface (flags=0, surface_rect=<optimized out>, surface=0xb0a02860, sink=0x88bd958) at gstvaapisink.c:1150

If I remove wl_display_dispatch_pending in frame callback sync:
There is backtrace,
// wl_display_sync callback with wl_display_dispatch_pending()
(gdb) bt
#0  0xb7c4ddd0 in _ecore_wl_input_cb_keyboard_enter () from /lib/libecore_wayland.so.1
#1  0xb6f16666 in ffi_call_SYSV () from /lib/libffi.so.6
#2  0xb6f163eb in ffi_call () from /lib/libffi.so.6
#3  0xb79a9ae5 in wl_closure_invoke () from /lib/libwayland-client.so.0
#4  0xb79a74c2 in dispatch_queue () from /lib/libwayland-client.so.0
#5  0xb79a803e in wl_display_dispatch_queue_pending () from /lib/libwayland-client.so.0
#6  0xb79a8162 in wl_display_dispatch_pending () from /lib/libwayland-client.so.0
#7  0xb3ca72a6 in gst_vaapi_window_wayland_sync (window=0x87d2d50) at gstvaapiwindow_wayland.c:162
#8  gst_vaapi_window_wayland_render (window=0x87d2d50, surface=0xb0a02860, src_rect=0xb017dbd0, dst_rect=0x88bdbe0, flags=0) at gstvaapiwindow_wayland.c:514
#9  0xb3c5a2fb in gst_vaapi_window_put_surface (window=0x87d2d50, surface=surface at entry=0xb0a02860, src_rect=0xb017dbd0, src_rect at entry=0x0, dst_rect=<optimized out>, dst_rect at entry=0x88bdbe0,
    flags=flags at entry=0) at gstvaapiwindow.c:435
#10 0xb3ccc1e1 in gst_vaapisink_put_surface (flags=0, surface_rect=<optimized out>, surface=0xb0a02860, sink=0x88bd958) at gstvaapisink.c:1150

// no wl_display_sync callback witt wl_display_displatch_pending
#0  0xb7c4ddd0 in _ecore_wl_input_cb_keyboard_enter () from /lib/libecore_wayland.so.1
#1  0xb6f16666 in ffi_call_SYSV () from /lib/libffi.so.6
#2  0xb6f163eb in ffi_call () from /lib/libffi.so.6
#3  0xb79a9ae5 in wl_closure_invoke () from /lib/libwayland-client.so.0
#4  0xb79a74c2 in dispatch_queue () from /lib/libwayland-client.so.0
#5  0xb79a803e in wl_display_dispatch_queue_pending () from /lib/libwayland-client.so.0
#6  0xb79a8162 in wl_display_dispatch_pending () from /lib/libwayland-client.so.0
#7  0xb3ca72a6 in gst_vaapi_window_wayland_sync (window=0x87d2950) at gstvaapiwindow_wayland.c:162
#8  gst_vaapi_window_wayland_render (window=0x87d2950, surface=0xb0a02860, src_rect=0xb017dbd0, dst_rect=0x88bd850, flags=0) at gstvaapiwindow_wayland.c:514
#9  0xb3c5a2fb in gst_vaapi_window_put_surface (window=0x87d2950, surface=surface at entry=0xb0a02860, src_rect=0xb017dbd0, src_rect at entry=0x0, dst_rect=<optimized out>, dst_rect at entry=0x88bd850,
    flags=flags at entry=0) at gstvaapiwindow.c:435

_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org<mailto:wayland-devel at lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131030/f8a0ffe4/attachment-0001.html>