<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="ZH-CN" link="blue" vlink="purple"> <div class="WordSection1"> For the wl_display_sync, is there possible scenario that:<o:p></o:p> <![if !supportLists]>1. <![endif]>Frame callback doesn’t come yet when it is checked <o:p></o:p> <![if !supportLists]>2. <![endif]>Frame callback comes immediately after the check<o:p></o:p> <![if !supportLists]>3. <![endif]>wl_display_dispatch_queue is called and is blocked since there is no event to dispatch on the queue.<o:p></o:p> Then application is blocked.<o:p></o:p> <o:p> </o:p> So, I still think the padding wl_display_sync is required.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> From: Jason Ekstrand [mailto:jason@jlekstrand.net] Sent: Tuesday, October 29, 2013 11:07 AM To: Zhao, Halley Cc: wayland-devel@lists.freedesktop.org; Antognolli, Rafael Subject: Re: Should I always add wl_display_sync() before wl_display_dispatch_queue()?<o:p></o:p> <o:p> </o:p> <div> <div> <o:p> </o:p> <div> On Mon, Oct 28, 2013 at 9:39 PM, Zhao, Halley <<a href="mailto:halley.zhao@intel.com" target="_blank">halley.zhao@intel.com</a>> wrote:<o:p></o:p> <div> <div> Video player use frame callback on an event queue, sometimes there is synchronization issue.<o:p></o:p> After looked at other usage of event queue, I found:<o:p></o:p> In order to avoid blocking by wl_display_dispatch_queue(), a padding callback of wl_display_sync is added on purpose.<o:p></o:p> Is my understanding correct?<o:p></o:p> Here is the changes:<o:p></o:p> <a href="https://gitorious.org/halley-test/gstreamer-vaapi/commit/9846c75e7a2bb223900457beffc3384c77cc5075" target="_blank">https://gitorious.org/halley-test/gstreamer-vaapi/commit/9846c75e7a2bb223900457beffc3384c77cc5075</a> <o:p></o:p> <o:p></o:p> <o:p></o:p> however, with or without the above change, I found there is still hangs in my player (efl based) : <o:p></o:p> <a href="https://gitorious.org/gst-plugins-vaapi/simple-player/source/87837fc1b4c11d7a33142c7d4fac1225d8973b80" target="_blank">https://gitorious.org/gst-plugins-vaapi/simple-player/source/87837fc1b4c11d7a33142c7d4fac1225d8973b80</a>:<o:p></o:p> it seems to be ECore issue during wl_display_dispatch_pending():<o:p></o:p> </div> </div> <div> <o:p> </o:p> </div> <div> 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.<o:p></o:p> </div> <div> 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: <a href="http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n1078">http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n1078</a><o:p></o:p> </div> <div> I hope that's helpful,<o:p></o:p> </div> <div> --Jason Ekstrand<o:p></o:p> </div> <div> <o:p></o:p> </div> <blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"> <div> <div> <o:p></o:p> Rafael:<o:p></o:p> Do you think it is an ECore issue?<o:p></o:p> <o:p></o:p> // wl_display_sync callback with wl_display_dispatch_pending()<o:p></o:p> (gdb) bt<o:p></o:p> #0 0xb7c4ddd0 in _ecore_wl_input_cb_keyboard_enter () from /lib/libecore_wayland.so.1<o:p></o:p> #1 0xb6f16666 in ffi_call_SYSV () from /lib/libffi.so.6<o:p></o:p> #2 0xb6f163eb in ffi_call () from /lib/libffi.so.6<o:p></o:p> #3 0xb79a9ae5 in wl_closure_invoke () from /lib/libwayland-client.so.0<o:p></o:p> #4 0xb79a74c2 in dispatch_queue () from /lib/libwayland-client.so.0<o:p></o:p> #5 0xb79a803e in wl_display_dispatch_queue_pending () from /lib/libwayland-client.so.0<o:p></o:p> #6 0xb79a8162 in wl_display_dispatch_pending () from /lib/libwayland-client.so.0<o:p></o:p> #7 0xb3ca72a6 in gst_vaapi_window_wayland_sync (window=0x87d2d50) at gstvaapiwindow_wayland.c:162<o:p></o:p> #8 gst_vaapi_window_wayland_render (window=0x87d2d50, surface=0xb0a02860, src_rect=0xb017dbd0, dst_rect=0x88bdbe0, flags=0) at gstvaapiwindow_wayland.c:514<o:p></o:p> #9 0xb3c5a2fb in gst_vaapi_window_put_surface (window=0x87d2d50, surface=surface@entry=0xb0a02860, src_rect=0xb017dbd0, src_rect@entry=0x0, dst_rect=<optimized out>, dst_rect@entry=0x88bdbe0, <o:p></o:p> flags=flags@entry=0) at gstvaapiwindow.c:435<o:p></o:p> #10 0xb3ccc1e1 in gst_vaapisink_put_surface (flags=0, surface_rect=<optimized out>, surface=0xb0a02860, sink=0x88bd958) at gstvaapisink.c:1150<o:p></o:p> <o:p></o:p> If I remove wl_display_dispatch_pending in frame callback sync:<o:p></o:p> There is backtrace, <o:p></o:p> // wl_display_sync callback with wl_display_dispatch_pending()<o:p></o:p> (gdb) bt<o:p></o:p> #0 0xb7c4ddd0 in _ecore_wl_input_cb_keyboard_enter () from /lib/libecore_wayland.so.1<o:p></o:p> #1 0xb6f16666 in ffi_call_SYSV () from /lib/libffi.so.6<o:p></o:p> #2 0xb6f163eb in ffi_call () from /lib/libffi.so.6<o:p></o:p> #3 0xb79a9ae5 in wl_closure_invoke () from /lib/libwayland-client.so.0<o:p></o:p> #4 0xb79a74c2 in dispatch_queue () from /lib/libwayland-client.so.0<o:p></o:p> #5 0xb79a803e in wl_display_dispatch_queue_pending () from /lib/libwayland-client.so.0<o:p></o:p> #6 0xb79a8162 in wl_display_dispatch_pending () from /lib/libwayland-client.so.0<o:p></o:p> #7 0xb3ca72a6 in gst_vaapi_window_wayland_sync (window=0x87d2d50) at gstvaapiwindow_wayland.c:162<o:p></o:p> #8 gst_vaapi_window_wayland_render (window=0x87d2d50, surface=0xb0a02860, src_rect=0xb017dbd0, dst_rect=0x88bdbe0, flags=0) at gstvaapiwindow_wayland.c:514<o:p></o:p> #9 0xb3c5a2fb in gst_vaapi_window_put_surface (window=0x87d2d50, surface=surface@entry=0xb0a02860, src_rect=0xb017dbd0, src_rect@entry=0x0, dst_rect=<optimized out>, dst_rect@entry=0x88bdbe0, <o:p></o:p> flags=flags@entry=0) at gstvaapiwindow.c:435<o:p></o:p> #10 0xb3ccc1e1 in gst_vaapisink_put_surface (flags=0, surface_rect=<optimized out>, surface=0xb0a02860, sink=0x88bd958) at gstvaapisink.c:1150<o:p></o:p> <o:p></o:p> // no wl_display_sync callback witt wl_display_displatch_pending<o:p></o:p> #0 0xb7c4ddd0 in _ecore_wl_input_cb_keyboard_enter () from /lib/libecore_wayland.so.1<o:p></o:p> #1 0xb6f16666 in ffi_call_SYSV () from /lib/libffi.so.6<o:p></o:p> #2 0xb6f163eb in ffi_call () from /lib/libffi.so.6<o:p></o:p> #3 0xb79a9ae5 in wl_closure_invoke () from /lib/libwayland-client.so.0<o:p></o:p> #4 0xb79a74c2 in dispatch_queue () from /lib/libwayland-client.so.0<o:p></o:p> #5 0xb79a803e in wl_display_dispatch_queue_pending () from /lib/libwayland-client.so.0<o:p></o:p> #6 0xb79a8162 in wl_display_dispatch_pending () from /lib/libwayland-client.so.0<o:p></o:p> #7 0xb3ca72a6 in gst_vaapi_window_wayland_sync (window=0x87d2950) at gstvaapiwindow_wayland.c:162<o:p></o:p> #8 gst_vaapi_window_wayland_render (window=0x87d2950, surface=0xb0a02860, src_rect=0xb017dbd0, dst_rect=0x88bd850, flags=0) at gstvaapiwindow_wayland.c:514<o:p></o:p> #9 0xb3c5a2fb in gst_vaapi_window_put_surface (window=0x87d2950, surface=surface@entry=0xb0a02860, src_rect=0xb017dbd0, src_rect@entry=0x0, dst_rect=<optimized out>, dst_rect@entry=0x88bd850, <o:p></o:p> flags=flags@entry=0) at gstvaapiwindow.c:435<o:p></o:p> </div> </div> _______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><o:p></o:p> </blockquote> </div> <o:p> </o:p> </div> </div> </div> </body> </html>