Pekka Paalanen wrote:
There was some talk about an alternative implementation: to let eglSwapBuffers never block, instead block when a rendering operation is about to use a buffer that should have already been made available by swapBuffers, but didn't actually happen yet. The DRM architecture should allow this. I wonder if this idea was forgotten or deemed to have problems...
I think the problem is that this would have to be tested for in virtually every EGL call, which may not be great for speed.
What I was proposing is that a wayland-aware egl code could use alternative calls so the swap is started without blocking, and another call to find out when the swap finishes. It's no longer using the egl interface, instead it is cheating and calling directly the stuff that eglSwapBuffers calls.
In any case none of this makes any difference to the underlying problem because there is still a blocking call in both of them.
Related to the above idea, the "buffer is now ready to be drawn to again" event could be delivered out-of-band, i.e. not in Wayland protocol stream, but e.g. via DRM. This is alternative to the DRM automatically blocking the client process on a rendering command.
This sounds like the right answer to me. Waiting for the buffer to be ready wants to ignore every event other than the buffer-release.
But all this still leaves the problem: eglSwapBuffers must send a Wayland attach request, and it may happen in a different thread than where the wl_display is being used. I believe this is the primary reason for "EGL makes [the old design] impossible".
This would work with client-controlled locking. The eglSwapBuffers implementation would call wl_lock()/wl_unlock() around the attach call, even though manually calling them is necessary in code directly calling wayland. This is because the egl emulation is more like a client library.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
