input handlig in separate thread

[Eugen Friedrich]

2013/10/20 Bill Spitzak <spitzak at gmail.com>

> On 10/19/2013 10:03 AM, Eugen Friedrich wrote:
>
>  Basically i would like to implement a thread(input thread) that should
>>   only dispatch incoming input events from wayland compositor when the
>> rendering thread is idle and the input thread should sleep in wait for
>> events function(i think poll on wl_display fd in the example above)
>> without blocking the rendering thread, because the input events are not
>> the only one trigger for rendering thread to start rendering again.
>> in this case the following code should be sufficient right?
>>
>> while(!quit)//main loop
>> {
>>       while (wl_display_prepare_read(__**display) != 0)
>>           wl_display_dispatch_pending(__**display);
>>
>>       wl_display_flush(display);
>>       poll(fds, nfds, -1); //wait until new input event arrives
>>       wl_display_read_events(__**display);
>>       wl_display_dispatch_pending(__**display);
>>
>> }
>>
>> And in this case are there some additional modifications/ wayland calls
>> in the egl (rendering thread) needed?
>>
>
> I'm not sure what you are getting at, but it sounds like in effect
> cooperative multitasking between this rendering thread and this thread. I
> think you are saying that the rendering thread will only operate when
> poll() is being called. I don't see any advantage of this over running a
> single thread that does the rendering just before calling poll(), which is
> what I was doing with the idle dispatch.
>
> The rendering thread can start rendering every time not only if poll is
called. The job of the input handling thread is to dispatch input events if
there is no rendering occurs. If the rendering thread is running the input
events are dispatched by the wl_display_dispatch call inside of the
eglSwapBuffers, but if the rendering stops (e.g. current animation is done)
we need to dispatch the input events somewhere else -> this is the aim of
the input thread.
So i'm trying to find a right way to do this without blocking the wayland
display main queue, because rendering can be started also without any
trigger from the input thread!!!

Also your above example can merge the wl_display_dispatch_pending calls
> like this:
>
>   while(!quit)//main loop
>   {
>         do wl_display_dispatch_pending(__**display);
>             while (wl_display_prepare_read(__**display) != 0);
>
>         wl_display_flush(display);
>         poll(fds, nfds, -1); //wait until new input event arrives
>         wl_display_read_events(__**display);
>   }
>
> If you move the wl_display_read_events up to the top with an if so it is
> not run the same time, you still have my wl_i_want_a_pony() function.
>
> What I am trying to find is if there ever is a reason to insert any client
> calls between all the functions I put in "wl_i_want_a_pony()".
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131020/2252d8f6/attachment.html>