how to deal with the last video frame buffer (wl_buffer)?

[Zhao, Halley]

Thanks Ander for your education.

1. I debugged Weston with simple-efl and found that wl_buffer isn't WL_BUFFER_RELEASE by weston_surface_attach (though there is weston_buffer_reference).
	It's good.

2. My failure case is in webkit which creates an internal wayland server, I will try more to see its difference from Weston.
	In webkit, my case failed with backtrace:
#0  0xb77a5424 in __kernel_vsyscall ()
#1  0xb5724b9b in poll () from /lib/libc.so.6
#2  0xb47f8074 in wl_display_dispatch_queue () from /lib/libwayland-client.so.0
#3  0xb4d18c21 in dri2_swap_buffers () from /lib/libEGL.so.1
#4  0xb4d0c3b5 in eglSwapBuffers () from /lib/libEGL.so.1
#5  0xb658e157 in WebCore::EGLWindowSurface::swapBuffers (this=0x8d5bb60)
    at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebCore/platform/graphics/surfaces/egl/EGLWaylandSurface.cpp:95
#6  0xb6dd601e in swapPlatformSurfaces (this=0x8bd7c00)
    at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebCore/platform/graphics/efl/tizen/AcceleratedPlatformLayer.cpp:320
#7  WebCore::AcceleratedPlatformLayer::swapPlatformSurfaces (this=0x8bd7c00)
    at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebCore/platform/graphics/efl/tizen/AcceleratedPlatformLayer.cpp:313
#8  0xb59b179e in WebCore::WebGraphicsLayer::swapPlatformSurfaces (this=0x9304b18)
    at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebKit2/WebProcess/WebPage/LayerTreeCoordinator/WebGraphicsLayer.cpp:884
#9  0xb59ab733 in WebKit::LayerTreeCoordinator::flushPendingLayerChanges (this=this at entry=0x88ab4e8)
    at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebKit2/WebProcess/WebPage/LayerTreeCoordinator/LayerTreeCoordinator.cpp:312
#10 0xb59aecb1 in flushPendingLayerChanges (this=0x88ab4e8)
    at /home/abuild/rpmbuild/BUILD/webkit2-efl-123997_0.11.47/Source/WebKit2/WebProcess/WebPage/LayerTreeCoordinator/LayerTreeCoordinator.cpp:286
#11 performScheduledLayerFlush (this=0x88ab4e8)

 
> -----Original Message-----
> From: Ander Conselvan de Oliveira [mailto:conselvan2 at gmail.com]
> Sent: Wednesday, September 04, 2013 5:12 PM
> To: Zhao, Halley
> Cc: wayland-devel at lists.freedesktop.org; Kondapally, Kalyan; Kristensen,
> Kristian H; Beauchesne, Gwenole
> Subject: Re: how to deal with the last video frame buffer (wl_buffer)?
> 
> On 09/03/2013 03:26 AM, Zhao, Halley wrote:
> > More questions:
> >
> > 1.I searched inside mesa code, there is wl_display_create_queue(),
> but
> > no wl_event_queue_destroy(), is it a bug?
> 
> That seems to be missing from the clean up path. However, before
> destroying the queue, we need to make sure there is no proxy that uses
> that queue, otherwise a crash would happen if the proxy received an
> event after the queue was destroyed.
> 
> > 2.I searched inside Weston code, there is no wl_buffer_send_release(),
> > is there other way to send the event of WL_BUFFER_RELEASE?
> 
> Look at weston_buffer_reference() in compositor.c. That function uses
> wl_resource_queue_event() to add the event to the connection buffer
> without flushing it and causing a context switch().
> 
> > 3.What's the design philosophy of wl_buffer_send_release?
> >
> > a)I had thought the event is sent when server doesn't use wl_buffer
> > any longer
> 
> That is correct.
> 
> > i.when a new wl_buffer is committed (release previous committed
> > buffer)
> >
> > ii.When the corresponding wl_surface is destroying (release the
> > committed buffer)
> >
> > iii.When a second wl_buffer is attached before commit (release the
> > previous attached one)
> 
> For the case of SHM buffers, the release event is sent after a texture
> upload, because at that moment a copy of the buffer is created. However,
> EGL buffers aren't copied so the release event is only sent when the
> buffer is replaced by a new one.
> 
> > b)However, the above assumption doesn't work well with mesa. With
> > nested server in webkit.
> >
> > Seems mesa requires wayland server send wl_buffer_send_release upon
> attach.
> 
> Could you elaborate on that?
> 
> 
> Cheers,
> Ander