How to release the weston_buffer after weston_view is destroyed.

[Pekka Paalanen]

On Mon, 13 Aug 2018 09:33:53 -0400
Sichem Zhou <sichem.zh at gmail.com> wrote:

> Hi Pekka,
> 
> Thanks for the reply. Sorry I forgot to say that `frame_callback` was a
> hack for me. It has historical reason. Initially I designed the client
> using EGL and found that I could only create the glprogram, creating
> shaders after having wl_surface. Since I used the same shader I thought
> that why creating new shaders every time when opening windows. So I decided
> to reuse shaders, where it set up the potential trap for me. However I
> found the `frame_callback` works really well for me, currently it is the
> most natural way.
> 
> Regarding the second problem, the client doesn't really send another frame
> immediately after receiving one. It renders based on input events, so it
> doesn't really send any frame if nothing new to render. Again, I designed
> it to save as much resources as I can. But thanks for your concern, I may
> switch to destroying `wl_surface` approach at next refactoring.

Hi,

ok, that explains. Did you have problems calling eglMakeCurrent()
without creating a wl_surface?

There is EGL_KHR_surfaceless_context extension that, if present, allows
calling eglMakeCurrent() with EGL_NO_SURFACE, so you can do all the GL
setup without a wl_surface.

You could also do the GL setup on the first show, and keep the shaders
etc. beyond the destruction of the wl_surface. I assume that should
work from EGL and GL point of view.


Thanks,
pq


> Le lun. 6 août 2018 04 h 44, Pekka Paalanen <ppaalanen at gmail.com> a écrit :
> 
> > 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/20180814/e7a46959/attachment.sig>