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. Thanks, Sichem Le lun. 6 août 2018 04 h 44, Pekka Paalanen <ppaala...@gmail.com> a écrit : > On Fri, 3 Aug 2018 18:04:36 -0400 > Sichem Zhou <sichem...@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 >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
