Re: wayland: how should dispatch the default wayland display queue?
On Tue, 29 Jul 2014 23:32:34 +0200 Eugen Friedrich fried...@gmail.com wrote: 2014-07-29 20:19 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 29 Jul 2014 13:00:14 +0200 Eugen Friedrich fried...@gmail.com wrote: 2014-07-28 12:29 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: 2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org: Hi Eugen, On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote: Hi Daniel, thanks, i understood we should add the wl_display_dispatch_pending call in the application there is currently no way to avoid this and basically it does not harm. I only wanted to understand if there is something missing. Doing that is not enough. Firstly, it requires the application to do this, or else EGL will break, which will make your stack appear broken with different applications. Secondly, as an application may do this in any thread, you could run into locking issues. wl_display_sync() does the following (paraphrased): callback = wl_display_roundtrip(); /* creates wl_callback object on default queue */ while (!callback_signalled) wl_display_dispatch(); /* dispatch default queue until callback processed */ Daniel, you swapped wl_display_sync() and wl_display_roundtrip() :). Yeah. :-P So, wl_display_roundtrip() is the function you should never use inside an EGL implementation. This violates the rule that EGL must not intefere with the default queue - meaning that the wl_callback object _cannot_ be placed on the main queue. In order to do this correctly, you will see Mesa does: callback = wl_display_roundtrip(); wl_callback_set_queue(callback, internal_egl_queue); while (!callback_signalled) wl_display_dispatch_queue(internal_egl_queue); As with all objects created by your EGL implementation, the wl_callback object must be moved to the queue immediately after it is created by wl_display_roundtrip(). Doing this will ensure correctness and also not require apps to be constantly dispatching the main queue. You can search the Mesa codebase for uses of wl_display_roundtrip() to find some examples of this pattern. Again - any object created by your EGL implementation that is not immediately moved to your internal event queue is a bug. Understood and our driver is basically is very similar to mesa in this respect but the wayland-compositor will send the delete_id event(delete the wl_display_sync callback) which is always goes to the default queue which is in some applications not dispatched, therefore the memory consumption is increasing in those applications. So as conclusion: each egl wayland client has to dispatch the default display queue on there own!? Obviously. See http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c for a stand-alone example that uses only libwayland-client, and not a toolkit. How did your app connect to Wayland and create the wl_surface that EGL then targets in the first place? It simply cannot do that without dispatching the default event queue. All properly written Wayland apps do that. Dispatching must also be part of the main loop. at the initialization app does dispatch the default queue but not during run time. I get a feeling there is something strange going on. What kind of app is this? Does it use a toolkit, or does it call libwayland-client directly? Is it perhaps running in an endless loop calling just GL functions and eglSwapBuffers but never any wayland functions? yes, the last one, just calling GL and eglSwapBuffers, for all input events it uses own queue and only this is dispatched. So at the end we have a 3 queues: - one for egl - egl is taking care for dispatching - one for input events - app is taking care for dispatching - one default queue - no body, which is a bug since the wayland display was created by the app and app is responsible to dispatch this even the event on this are triggered by egl. Will force application developers to include wl_display_dispatch_pending in their main loop. Thanks for the support, your comments are very welcome Hmm, which version of libwayland are you using again? I am looking at wayland-client.c, and the client wl_display contains two queues: the default queue, and the internal display queue. All events on the wl_display object go to the internal display queue, and it seems that queue is dispatched always when any queue is dispatched. That means that wl_display.delete_id events would be handled regardless of which queue you dispatch. Before adding the internal queue for wl_display, libwayland-client indeed did rely on the app to dispatch the main queue regularly. So I'm not
Re: wayland: how should dispatch the default wayland display queue?
Hello Pekka, now i have the complete picture, the mentioned commit describes exactly the problem which was found by me. we are still using wayland 1.3 version. thanks a lot !!! 2014-07-30 8:38 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 29 Jul 2014 23:32:34 +0200 Eugen Friedrich fried...@gmail.com wrote: 2014-07-29 20:19 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 29 Jul 2014 13:00:14 +0200 Eugen Friedrich fried...@gmail.com wrote: 2014-07-28 12:29 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: 2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org: Hi Eugen, On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote: Hi Daniel, thanks, i understood we should add the wl_display_dispatch_pending call in the application there is currently no way to avoid this and basically it does not harm. I only wanted to understand if there is something missing. Doing that is not enough. Firstly, it requires the application to do this, or else EGL will break, which will make your stack appear broken with different applications. Secondly, as an application may do this in any thread, you could run into locking issues. wl_display_sync() does the following (paraphrased): callback = wl_display_roundtrip(); /* creates wl_callback object on default queue */ while (!callback_signalled) wl_display_dispatch(); /* dispatch default queue until callback processed */ Daniel, you swapped wl_display_sync() and wl_display_roundtrip() :). Yeah. :-P So, wl_display_roundtrip() is the function you should never use inside an EGL implementation. This violates the rule that EGL must not intefere with the default queue - meaning that the wl_callback object _cannot_ be placed on the main queue. In order to do this correctly, you will see Mesa does: callback = wl_display_roundtrip(); wl_callback_set_queue(callback, internal_egl_queue); while (!callback_signalled) wl_display_dispatch_queue(internal_egl_queue); As with all objects created by your EGL implementation, the wl_callback object must be moved to the queue immediately after it is created by wl_display_roundtrip(). Doing this will ensure correctness and also not require apps to be constantly dispatching the main queue. You can search the Mesa codebase for uses of wl_display_roundtrip() to find some examples of this pattern. Again - any object created by your EGL implementation that is not immediately moved to your internal event queue is a bug. Understood and our driver is basically is very similar to mesa in this respect but the wayland-compositor will send the delete_id event(delete the wl_display_sync callback) which is always goes to the default queue which is in some applications not dispatched, therefore the memory consumption is increasing in those applications. So as conclusion: each egl wayland client has to dispatch the default display queue on there own!? Obviously. See http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c for a stand-alone example that uses only libwayland-client, and not a toolkit. How did your app connect to Wayland and create the wl_surface that EGL then targets in the first place? It simply cannot do that without dispatching the default event queue. All properly written Wayland apps do that. Dispatching must also be part of the main loop. at the initialization app does dispatch the default queue but not during run time. I get a feeling there is something strange going on. What kind of app is this? Does it use a toolkit, or does it call libwayland-client directly? Is it perhaps running in an endless loop calling just GL functions and eglSwapBuffers but never any wayland functions? yes, the last one, just calling GL and eglSwapBuffers, for all input events it uses own queue and only this is dispatched. So at the end we have a 3 queues: - one for egl - egl is taking care for dispatching - one for input events - app is taking care for dispatching - one default queue - no body, which is a bug since the wayland display was created by the app and app is responsible to dispatch this even the event on this are triggered by egl. Will force application developers to include wl_display_dispatch_pending in their main loop. Thanks for the support, your comments are very welcome Hmm, which version of libwayland are you using again? I am looking at wayland-client.c, and the client wl_display contains two queues: the default queue, and the internal display queue. All
Re: wayland: how should dispatch the default wayland display queue?
2014-07-28 12:29 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: 2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org: Hi Eugen, On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote: Hi Daniel, thanks, i understood we should add the wl_display_dispatch_pending call in the application there is currently no way to avoid this and basically it does not harm. I only wanted to understand if there is something missing. Doing that is not enough. Firstly, it requires the application to do this, or else EGL will break, which will make your stack appear broken with different applications. Secondly, as an application may do this in any thread, you could run into locking issues. wl_display_sync() does the following (paraphrased): callback = wl_display_roundtrip(); /* creates wl_callback object on default queue */ while (!callback_signalled) wl_display_dispatch(); /* dispatch default queue until callback processed */ Daniel, you swapped wl_display_sync() and wl_display_roundtrip() :). This violates the rule that EGL must not intefere with the default queue - meaning that the wl_callback object _cannot_ be placed on the main queue. In order to do this correctly, you will see Mesa does: callback = wl_display_roundtrip(); wl_callback_set_queue(callback, internal_egl_queue); while (!callback_signalled) wl_display_dispatch_queue(internal_egl_queue); As with all objects created by your EGL implementation, the wl_callback object must be moved to the queue immediately after it is created by wl_display_roundtrip(). Doing this will ensure correctness and also not require apps to be constantly dispatching the main queue. You can search the Mesa codebase for uses of wl_display_roundtrip() to find some examples of this pattern. Again - any object created by your EGL implementation that is not immediately moved to your internal event queue is a bug. Understood and our driver is basically is very similar to mesa in this respect but the wayland-compositor will send the delete_id event(delete the wl_display_sync callback) which is always goes to the default queue which is in some applications not dispatched, therefore the memory consumption is increasing in those applications. So as conclusion: each egl wayland client has to dispatch the default display queue on there own!? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
On Tue, 29 Jul 2014 13:00:14 +0200 Eugen Friedrich fried...@gmail.com wrote: 2014-07-28 12:29 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: 2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org: Hi Eugen, On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote: Hi Daniel, thanks, i understood we should add the wl_display_dispatch_pending call in the application there is currently no way to avoid this and basically it does not harm. I only wanted to understand if there is something missing. Doing that is not enough. Firstly, it requires the application to do this, or else EGL will break, which will make your stack appear broken with different applications. Secondly, as an application may do this in any thread, you could run into locking issues. wl_display_sync() does the following (paraphrased): callback = wl_display_roundtrip(); /* creates wl_callback object on default queue */ while (!callback_signalled) wl_display_dispatch(); /* dispatch default queue until callback processed */ Daniel, you swapped wl_display_sync() and wl_display_roundtrip() :). Yeah. :-P So, wl_display_roundtrip() is the function you should never use inside an EGL implementation. This violates the rule that EGL must not intefere with the default queue - meaning that the wl_callback object _cannot_ be placed on the main queue. In order to do this correctly, you will see Mesa does: callback = wl_display_roundtrip(); wl_callback_set_queue(callback, internal_egl_queue); while (!callback_signalled) wl_display_dispatch_queue(internal_egl_queue); As with all objects created by your EGL implementation, the wl_callback object must be moved to the queue immediately after it is created by wl_display_roundtrip(). Doing this will ensure correctness and also not require apps to be constantly dispatching the main queue. You can search the Mesa codebase for uses of wl_display_roundtrip() to find some examples of this pattern. Again - any object created by your EGL implementation that is not immediately moved to your internal event queue is a bug. Understood and our driver is basically is very similar to mesa in this respect but the wayland-compositor will send the delete_id event(delete the wl_display_sync callback) which is always goes to the default queue which is in some applications not dispatched, therefore the memory consumption is increasing in those applications. So as conclusion: each egl wayland client has to dispatch the default display queue on there own!? Obviously. See http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c for a stand-alone example that uses only libwayland-client, and not a toolkit. How did your app connect to Wayland and create the wl_surface that EGL then targets in the first place? It simply cannot do that without dispatching the default event queue. All properly written Wayland apps do that. Dispatching must also be part of the main loop. I get a feeling there is something strange going on. What kind of app is this? Does it use a toolkit, or does it call libwayland-client directly? Is it perhaps running in an endless loop calling just GL functions and eglSwapBuffers but never any wayland functions? I suppose one could do that mistake and never dispatch the main event queue if the app never does anything with input, but that is quite a special case. And in fact, it would not work right. Xdg_shell protocol (only if you run a desktop, though) has a ping-pong event/request that must be reacted to, otherwise the app is deemed unresponsive and handled specially, e.g. the window could be grayed out completely. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
2014-07-29 20:19 GMT+02:00 Pekka Paalanen ppaala...@gmail.com: On Tue, 29 Jul 2014 13:00:14 +0200 Eugen Friedrich fried...@gmail.com wrote: 2014-07-28 12:29 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: 2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org: Hi Eugen, On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote: Hi Daniel, thanks, i understood we should add the wl_display_dispatch_pending call in the application there is currently no way to avoid this and basically it does not harm. I only wanted to understand if there is something missing. Doing that is not enough. Firstly, it requires the application to do this, or else EGL will break, which will make your stack appear broken with different applications. Secondly, as an application may do this in any thread, you could run into locking issues. wl_display_sync() does the following (paraphrased): callback = wl_display_roundtrip(); /* creates wl_callback object on default queue */ while (!callback_signalled) wl_display_dispatch(); /* dispatch default queue until callback processed */ Daniel, you swapped wl_display_sync() and wl_display_roundtrip() :). Yeah. :-P So, wl_display_roundtrip() is the function you should never use inside an EGL implementation. This violates the rule that EGL must not intefere with the default queue - meaning that the wl_callback object _cannot_ be placed on the main queue. In order to do this correctly, you will see Mesa does: callback = wl_display_roundtrip(); wl_callback_set_queue(callback, internal_egl_queue); while (!callback_signalled) wl_display_dispatch_queue(internal_egl_queue); As with all objects created by your EGL implementation, the wl_callback object must be moved to the queue immediately after it is created by wl_display_roundtrip(). Doing this will ensure correctness and also not require apps to be constantly dispatching the main queue. You can search the Mesa codebase for uses of wl_display_roundtrip() to find some examples of this pattern. Again - any object created by your EGL implementation that is not immediately moved to your internal event queue is a bug. Understood and our driver is basically is very similar to mesa in this respect but the wayland-compositor will send the delete_id event(delete the wl_display_sync callback) which is always goes to the default queue which is in some applications not dispatched, therefore the memory consumption is increasing in those applications. So as conclusion: each egl wayland client has to dispatch the default display queue on there own!? Obviously. See http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c for a stand-alone example that uses only libwayland-client, and not a toolkit. How did your app connect to Wayland and create the wl_surface that EGL then targets in the first place? It simply cannot do that without dispatching the default event queue. All properly written Wayland apps do that. Dispatching must also be part of the main loop. at the initialization app does dispatch the default queue but not during run time. I get a feeling there is something strange going on. What kind of app is this? Does it use a toolkit, or does it call libwayland-client directly? Is it perhaps running in an endless loop calling just GL functions and eglSwapBuffers but never any wayland functions? yes, the last one, just calling GL and eglSwapBuffers, for all input events it uses own queue and only this is dispatched. So at the end we have a 3 queues: - one for egl - egl is taking care for dispatching - one for input events - app is taking care for dispatching - one default queue - no body, which is a bug since the wayland display was created by the app and app is responsible to dispatch this even the event on this are triggered by egl. Will force application developers to include wl_display_dispatch_pending in their main loop. Thanks for the support, your comments are very welcome I suppose one could do that mistake and never dispatch the main event queue if the app never does anything with input, but that is quite a special case. And in fact, it would not work right. Xdg_shell protocol (only if you run a desktop, though) has a ping-pong event/request that must be reacted to, otherwise the app is deemed unresponsive and handled specially, e.g. the window could be grayed out completely. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
2014-07-27 22:50 GMT+03:00 Eugen Friedrich fried...@gmail.com: O thanks for the hint about mailing list, and for clarification on the dispatching logic(I'm not original English speaker and assume havok is like behavior? ) to break havoc means creating trouble ;). 2014-07-27 21:33 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: FIY, You dropped the mailing list in your reply. 2014-07-27 22:15 GMT+03:00 Eugen Friedrich fried...@gmail.com: The problem is the app never calls wl_display_distpath(_pending) it just creates native handles and then uses EGL for rendering and the events on the main wayland display queue are never dispatched I think if EGL triggers the event(ba calling wl_diplay_sync) it should be also responsible for dispatching EGL should not dispatch the main queue, that would break havok in the apps. What you should do is dispatch the main queue in your app's main loop. 2014-07-27 20:42 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: 2014-07-27 21:14 GMT+03:00 Eugen Friedrich fried...@gmail.com: Hi all, after debugging a memory consumption issue in simple wayland application i found a issue in our wayland graphics backend. Then i took a look into the mesa implementation and found the quite similar implementation there. Our graphics stack creates it's own wayland queue and uses this queue for all wayland objects and only this queue will be dispatched. Our graphics stack calls also wl_display_sync api and the issue is that the wayland library will send a delete event which will go to the default queue of wayland display but this is never dispatched from the driver and the memory consumption increases. So should the graphics stack dispatch also the default queue or should application call somewhere wl_display_dispatch_pending? I don't see why the memory consumption should increase. The app should call wl_display_distpath(_pending) in its main loop, but I'm afraid i don't quite understand your problem. -- Giulio ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
Hi Eugen, On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote: Hi Daniel, thanks, i understood we should add the wl_display_dispatch_pending call in the application there is currently no way to avoid this and basically it does not harm. I only wanted to understand if there is something missing. Doing that is not enough. Firstly, it requires the application to do this, or else EGL will break, which will make your stack appear broken with different applications. Secondly, as an application may do this in any thread, you could run into locking issues. wl_display_sync() does the following (paraphrased): callback = wl_display_roundtrip(); /* creates wl_callback object on default queue */ while (!callback_signalled) wl_display_dispatch(); /* dispatch default queue until callback processed */ This violates the rule that EGL must not intefere with the default queue - meaning that the wl_callback object _cannot_ be placed on the main queue. In order to do this correctly, you will see Mesa does: callback = wl_display_roundtrip(); wl_callback_set_queue(callback, internal_egl_queue); while (!callback_signalled) wl_display_dispatch_queue(internal_egl_queue); As with all objects created by your EGL implementation, the wl_callback object must be moved to the queue immediately after it is created by wl_display_roundtrip(). Doing this will ensure correctness and also not require apps to be constantly dispatching the main queue. You can search the Mesa codebase for uses of wl_display_roundtrip() to find some examples of this pattern. Again - any object created by your EGL implementation that is not immediately moved to your internal event queue is a bug. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
2014-07-28 13:19 GMT+03:00 Daniel Stone dan...@fooishbar.org: Hi Eugen, On 27 July 2014 22:16, Eugen Friedrich fried...@gmail.com wrote: Hi Daniel, thanks, i understood we should add the wl_display_dispatch_pending call in the application there is currently no way to avoid this and basically it does not harm. I only wanted to understand if there is something missing. Doing that is not enough. Firstly, it requires the application to do this, or else EGL will break, which will make your stack appear broken with different applications. Secondly, as an application may do this in any thread, you could run into locking issues. wl_display_sync() does the following (paraphrased): callback = wl_display_roundtrip(); /* creates wl_callback object on default queue */ while (!callback_signalled) wl_display_dispatch(); /* dispatch default queue until callback processed */ Daniel, you swapped wl_display_sync() and wl_display_roundtrip() :). This violates the rule that EGL must not intefere with the default queue - meaning that the wl_callback object _cannot_ be placed on the main queue. In order to do this correctly, you will see Mesa does: callback = wl_display_roundtrip(); wl_callback_set_queue(callback, internal_egl_queue); while (!callback_signalled) wl_display_dispatch_queue(internal_egl_queue); As with all objects created by your EGL implementation, the wl_callback object must be moved to the queue immediately after it is created by wl_display_roundtrip(). Doing this will ensure correctness and also not require apps to be constantly dispatching the main queue. You can search the Mesa codebase for uses of wl_display_roundtrip() to find some examples of this pattern. Again - any object created by your EGL implementation that is not immediately moved to your internal event queue is a bug. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
2014-07-27 21:14 GMT+03:00 Eugen Friedrich fried...@gmail.com: Hi all, after debugging a memory consumption issue in simple wayland application i found a issue in our wayland graphics backend. Then i took a look into the mesa implementation and found the quite similar implementation there. Our graphics stack creates it's own wayland queue and uses this queue for all wayland objects and only this queue will be dispatched. Our graphics stack calls also wl_display_sync api and the issue is that the wayland library will send a delete event which will go to the default queue of wayland display but this is never dispatched from the driver and the memory consumption increases. So should the graphics stack dispatch also the default queue or should application call somewhere wl_display_dispatch_pending? I don't see why the memory consumption should increase. The app should call wl_display_distpath(_pending) in its main loop, but I'm afraid i don't quite understand your problem. -- Giulio ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
FIY, You dropped the mailing list in your reply. 2014-07-27 22:15 GMT+03:00 Eugen Friedrich fried...@gmail.com: The problem is the app never calls wl_display_distpath(_pending) it just creates native handles and then uses EGL for rendering and the events on the main wayland display queue are never dispatched I think if EGL triggers the event(ba calling wl_diplay_sync) it should be also responsible for dispatching EGL should not dispatch the main queue, that would break havok in the apps. What you should do is dispatch the main queue in your app's main loop. 2014-07-27 20:42 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: 2014-07-27 21:14 GMT+03:00 Eugen Friedrich fried...@gmail.com: Hi all, after debugging a memory consumption issue in simple wayland application i found a issue in our wayland graphics backend. Then i took a look into the mesa implementation and found the quite similar implementation there. Our graphics stack creates it's own wayland queue and uses this queue for all wayland objects and only this queue will be dispatched. Our graphics stack calls also wl_display_sync api and the issue is that the wayland library will send a delete event which will go to the default queue of wayland display but this is never dispatched from the driver and the memory consumption increases. So should the graphics stack dispatch also the default queue or should application call somewhere wl_display_dispatch_pending? I don't see why the memory consumption should increase. The app should call wl_display_distpath(_pending) in its main loop, but I'm afraid i don't quite understand your problem. -- Giulio ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
O thanks for the hint about mailing list, and for clarification on the dispatching logic(I'm not original English speaker and assume havok is like behavior? ) 2014-07-27 21:33 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: FIY, You dropped the mailing list in your reply. 2014-07-27 22:15 GMT+03:00 Eugen Friedrich fried...@gmail.com: The problem is the app never calls wl_display_distpath(_pending) it just creates native handles and then uses EGL for rendering and the events on the main wayland display queue are never dispatched I think if EGL triggers the event(ba calling wl_diplay_sync) it should be also responsible for dispatching EGL should not dispatch the main queue, that would break havok in the apps. What you should do is dispatch the main queue in your app's main loop. 2014-07-27 20:42 GMT+02:00 Giulio Camuffo giuliocamu...@gmail.com: 2014-07-27 21:14 GMT+03:00 Eugen Friedrich fried...@gmail.com: Hi all, after debugging a memory consumption issue in simple wayland application i found a issue in our wayland graphics backend. Then i took a look into the mesa implementation and found the quite similar implementation there. Our graphics stack creates it's own wayland queue and uses this queue for all wayland objects and only this queue will be dispatched. Our graphics stack calls also wl_display_sync api and the issue is that the wayland library will send a delete event which will go to the default queue of wayland display but this is never dispatched from the driver and the memory consumption increases. So should the graphics stack dispatch also the default queue or should application call somewhere wl_display_dispatch_pending? I don't see why the memory consumption should increase. The app should call wl_display_distpath(_pending) in its main loop, but I'm afraid i don't quite understand your problem. -- Giulio ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
Hi Eugen, On Sunday, July 27, 2014, Eugen Friedrich fried...@gmail.com wrote: Our graphics stack creates it's own wayland queue and uses this queue for all wayland objects and only this queue will be dispatched. Our graphics stack calls also wl_display_sync api and the issue is that the wayland library will send a delete event which will go to the default queue of wayland display but this is never dispatched from the driver and the memory consumption increases. So should the graphics stack dispatch also the default queue or should application call somewhere wl_display_dispatch_pending? The EGL implementation must never dispatch the default queue. There is a new convenience call in development to fix this, but for now, you have to call wl_display_roundtrip, wl_callback_set_queue, and wl_callback_add_listener. You can see this used in Mesa. Hope this helps. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland: how should dispatch the default wayland display queue?
Hi Daniel, thanks, i understood we should add the wl_display_dispatch_pending call in the application there is currently no way to avoid this and basically it does not harm. I only wanted to understand if there is something missing. 2014-07-27 22:41 GMT+02:00 Daniel Stone dan...@fooishbar.org: Hi Eugen, On Sunday, July 27, 2014, Eugen Friedrich fried...@gmail.com wrote: Our graphics stack creates it's own wayland queue and uses this queue for all wayland objects and only this queue will be dispatched. Our graphics stack calls also wl_display_sync api and the issue is that the wayland library will send a delete event which will go to the default queue of wayland display but this is never dispatched from the driver and the memory consumption increases. So should the graphics stack dispatch also the default queue or should application call somewhere wl_display_dispatch_pending? The EGL implementation must never dispatch the default queue. There is a new convenience call in development to fix this, but for now, you have to call wl_display_roundtrip, wl_callback_set_queue, and wl_callback_add_listener. You can see this used in Mesa. Hope this helps. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
