why wi_surface_frame callback delay two frames

[Pekka Paalanen]

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
wl_buffer.release.

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: 
http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland
http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/platform_wayland.c

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:
http://ppaalanen.blogspot.fi/2012/11/on-supporting-wayland-gl-clients-and.html
That should be nothing new for you at this point.


Thanks.
pq