On Mon, 13 Aug 2018 09:33:53 -0400 Sichem Zhou <[email protected]> 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 <[email protected]> a écrit : > > > On Fri, 3 Aug 2018 18:04:36 -0400 > > Sichem Zhou <[email protected]> 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 > >
pgp8EhBDz6BUq.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
