why wi_surface_frame callback delay two frames
ppaalanen at gmail.com
Tue May 5 03:48:07 PDT 2015
On Tue, 5 May 2015 09:14:42 +0000
Nancy Zou <Nancy.Zou at csr.com> wrote:
> Hi Pekka
> >>how do you differ from the main loops and event handlers in Weston's simple-shm.c or simple-egl.c?
> >>Are you using EGL? Which implementation of EGL?
> I try to do a implementation for the wayland-egl flip driver because my linux sgx driver don't support wayland now. When I do it, I refer the simple-shm.c. My test case is simple-egl.c.
> I want to mark client buffer status like the android BufferQueue do. When one frame call back, the buffer status will be free. But I find buffer free is always delay.
Yes, the compositor can hold on to the buffer for longer periods of
time. However, we are not talking about wl_surface.frame here, but
When the compositor holds the buffer reserved, you should generally
allocate a new one, if you have none available.
If the compositor is using the buffer for direct scanout, and the
client replaces it for a wl_surface, the buffer will be released after
the new update has hit the screen, which is after the frame callback
for the *new* content.
You have to be careful, but under some conditions, it is enough to wait
for a wl_buffer.release if you have no buffers available. In most cases
it is possible to do with just two buffers, if you wait for the release
of the old one.
> >> Is your main loop flushing and waiting properly? For the simple case, see simple-shm.c. For more complicated case, see http://wayland.freedesktop.org/docs/html/apb.html#Client-classwl__display
> and wl_display_prepare_read() and wl_display_read_events().
> I don't use wl_display_prepare_read() and wl_display_read_events(). I call wl_display_flush after the wl_surface_commit which will be called by eglSwapBuffers(). Should I call wl_display_flush when the client is end? The simple-egl have already called it.
You are writing an EGL implementation? Inside EGL, you must use your
own wl_event_queue, and never dispatch the default queue. This is
important for all events the EGL might be receiving or waiting for.
wl_display_flush() after committing new contents is likely required
inside eglSwapBuffers, so that is ok.
The best reference we have is Mesa:
And now that I look at it, it probably has problems with multi-threaded
apps (the conflict between the prepare_read/read_events/dispatch_pending
API and wl_display_dispatch API).
Did you already find:
That should be nothing new for you at this point.
More information about the wayland-devel