How to release the weston_buffer after weston_view is destroyed.

[Pekka Paalanen]

On Fri, 3 Aug 2018 18:04:36 -0400
Sichem Zhou <sichem.zh at gmail.com> wrote:

> Hi Pekka,
> 
> Thanks for your reply. Yes, preferably if I can hide the map and unmap from
> client, in this case I cannot because it is part of a desktop shell. After
> I unmap it and remap the view next time, it is not expected the shell to
> continue from last draw. I would want the shell be drawing total different
> things instead. If I simply remap, I shall see the last frame that did get
> drawed.
> 
> It can be seen as a problem in the application, designing smarter clients
> which is aware of such details, by not sending the last frame for example,
> but I found an easier solution by unmap the view in the `frame_signal`. It
> worked quite well.

Hi,

if you need the unmap to happen immediately without round-tripping to
the helper client, I think a good solution for your case would be for
the desktop-shell to unmap the surface and send an event to the helper
client telling that the surface is unmapped. That way the client can
destroy the wl_surface, which will make the compositor automatically
release buffers it might have held, and there is no chance of showing
outdated content on the next time.

In my opinion, the frame_signal solution is a hack. It is not really
meant for what you are doing it with it, and it does not allow the
compositor to release buffers it would not have released anyway.

It also does not guarantee that the client would not block inside
eglSwapBuffers, you have to prevent that in the client anyway. Usually
unmapping a window permanently is initiated by the client by e.g.
destroying the wl_surface, which naturally avoids an indefinite wait
for a frame callback. That could be a response to a specific event.

With the frame_signal hack, even if you unmap the view after sending
out the frame callbacks, what will guarantee that the client will not
post another frame as a response to the frame callback you just sent?
And then another frame after that would again hit the indefinite
blocking inside eglSwapBuffers(). I suspect your design is quite
fragile as is.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180806/bbaf4cec/attachment.sig>