On 04/24/2012 09:15 AM, Arnaud Vrac wrote:
Sorry for probably wasting your time, but why does "EGL make this
impossible"?
Because eglSwapBuffers is unfortunately a blocking call.
After reading all these emails a bunch more times, I *think* I
understand the problem.
First of all, this is for "EGL atop Wayland" (an EGL implementation that
uses Wayland), not "Wayland atop EGL" (a Wayland compositor that uses
EGL to do all it's work). That is mostly what confused me.
The EGL spec says that after eglSwapBuffers returns the former back
buffer is not being used for display and can be drawn on. Unless an
otherwise unnecessary copy is done, the only way to do this in Wayland
is to do an attach and then wait for Wayland to respond that the old
buffer is not attached any more. This is the blocking, correct?
This is less than ideal. If a thread wants to update two EGL surfaces,
it cannot start the swap on the second one until the first one finishes
swapping, and can't draw anything in the second one while waiting for
the swap of the first. Therefore I would expect a non-EGL workaround to
be added that allows this, perhaps a client can call wl_egl_start_swap()
and later wl_egl_wait_for_swap(). eglSwapBuffers would just do these two
in a row.
I think the thread is only interested in buffer-free events and are
unprepared for mouse clicks to be handled while they are still cleaning
up their drawing (I would not be surprised if the mouse click tries to
grab the same lock the drawing code is holding and deadlocks). So it is
much more likely that any filtering of events is "only do callbacks for
buffer-free events for this object", not "only do callbacks for this
object".
So I would propose that the actual problem be attacked. I think what is
needed "wl_wait_for_buffer_release(surface)" api. The result of this
call is that when it returns you know that all attach calls for this
surface have completed (it would return immediately if there were no
attach calls). No callbacks would happen in this thread while it is
waiting. There should also be client-level locking of wayland, a
multithreaded client must itself lock wayland around any calls,
including this one (calls that block will internally release the lock
while blocking).
I'm not sure if this solves anything, but I think limiting the problem
to this one call makes it easier to think about solutions, and also
provides a call that is useful for other drawing systems than EGL. One
idea this makes possible is to put the buffer-release events into their
own socket.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
