Re: frame callbacks and sub_surfaces
On Mon, 7 Nov 2022 15:49:16 -0800 Joel Winarske wrote: > @pq > I think this approach might better suit our use cases (CI health gate / > client regression testing): > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/24 > > I would be happy to push this forward, seeing it hasn't moved much. Hi, you are welcome to chime in there. You could start by reviewing it and commenting on how it fits your use cases, particularly about the suggstion to add that information to the scene-graph scope compared to having its own scope. I see the original submitter has been occasionally active over several years, so maybe also ask if they are happy for you to run with it. Thanks, pq pgpN8n4oLzvSO.pgp Description: OpenPGP digital signature
Re: frame callbacks and sub_surfaces
> There's https://gitlab.freedesktop.org/wayland/wayland/-/issues/266 about this. Thanks, yes I have that book marked. @pq I think this approach might better suit our use cases (CI health gate / client regression testing): https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/24 I would be happy to push this forward, seeing it hasn't moved much. Joel
Re: frame callbacks and sub_surfaces
On 2022-11-07 10:27, Pekka Paalanen wrote: > On Sat, 5 Nov 2022 16:14:44 -0700 > Joel Winarske wrote: > >> Does the base surface ever get occluded? > > Anything could be occluded or off-screen at any time. > > However, if parent surface is completely occluded/off-screen, then that > should not freeze any of its sub-surfaces that are visible, even if > they are in synchronized mode. So I think the implication of that is > that if any sub-surface is visible, then the parent surface should be > reporting frame callbacks and do everything else as if it was visible > too. > > A good question, I wonder if anyone tests compositors for that... > > I'm not sure if even Weston handles that correctly. > > This is not explicitly mandated by the protocol specification IIRC, it's > more about compositors doing what would look right to an end user. There's https://gitlab.freedesktop.org/wayland/wayland/-/issues/266 about this. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Re: frame callbacks and sub_surfaces
On Sat, 5 Nov 2022 16:14:44 -0700 Joel Winarske wrote: > Okay thanks for the input. I sorted it out, and it's working great. > > My learning - Simply implement a frame callback for each sub surface and > base surface, empty or otherwise. No need for any other commit calls. > > What is the recommended solution for counting frame rate with sub > surfaces? Are you not usually interested about how many times you have re-drawn? So you'd count have times you draw, subject to what whatever frame rate throttling you choose to use. > Does the base surface ever get occluded? Anything could be occluded or off-screen at any time. However, if parent surface is completely occluded/off-screen, then that should not freeze any of its sub-surfaces that are visible, even if they are in synchronized mode. So I think the implication of that is that if any sub-surface is visible, then the parent surface should be reporting frame callbacks and do everything else as if it was visible too. A good question, I wonder if anyone tests compositors for that... I'm not sure if even Weston handles that correctly. This is not explicitly mandated by the protocol specification IIRC, it's more about compositors doing what would look right to an end user. Thanks, pq pgpNhg2ESchqJ.pgp Description: OpenPGP digital signature
Re: frame callbacks and sub_surfaces
Okay thanks for the input. I sorted it out, and it's working great. My learning - Simply implement a frame callback for each sub surface and base surface, empty or otherwise. No need for any other commit calls. What is the recommended solution for counting frame rate with sub surfaces? Does the base surface ever get occluded? Thanks, Joel On Wed, Nov 2, 2022 at 2:04 AM Pekka Paalanen wrote: > On Tue, 1 Nov 2022 20:08:10 -0700 > Joel Winarske wrote: > > > Thanks for the clarification. Much appreciated. > > > > I'm interested in implementing a sub-surface example. Is a MR/PR of > > interest? > > To which repository, and what do you want to demonstrate with it? > > E.g. > > https://gitlab.freedesktop.org/wayland/weston/-/blob/main/clients/subsurfaces.c > exists already. > > Wayland repository can take documentation explaining all that better, > but I'm not sure examples are in scope there. Maybe wayland-utils could > have test programs better than weston repository, but I don't know > about examples. Maybe others have ideas? > > Unless for special reasons, one should use a ready-made toolkit instead > of programming apps directly for Wayland anyway. > > > Thanks, > pq >
Re: frame callbacks and sub_surfaces
On Thu, 3 Nov 2022 15:14:00 -0700 Joel Winarske wrote: > Hi pq, > > I was thinking of a more full-featured example using sub surfaces with > runtime positioning and z-order control. > > That aside I am having an interesting problem. In case of multiple > surfaces, I only see the frame event for the last added surface. > > Surface A is behind B and C (tiled), none occluded. > > Here I get a frame callback for B. I'm using the commit pattern from B to > Base. > Surface B > Surface A > Base > > Adding sub surface C, with registered callbacks for B and C, I only see a > frame callback for C. I'm using the commit pattern from C to Base. > Surface C > Surface B > Surface A > Base > > I don't touch the B callback when the C callback is added. Please, be more specific about which requests and when you are sending. From the above, I can guess the wl_surface.commit requests, but I do not see when exactly you do e.g. wl_surface.frame and on which surface. > Does anything stand out? The only guess I have is that you missed this part from wl_surface.frame specification: > The notification will only be posted for one frame unless requested > again. and > The object returned by this request will be destroyed by the > compositor after the callback is fired and as such the client must > not attempt to use it after that point. So every time you want to receive a frame callback, you need to create a new wl_callback object with wl_surface.frame. And every time wl_callback.done is delivered, you must destroy the wl_callback. You can also destroy the wl_callback at any time, if you are no longer interested in it. Thanks, pq pgpx8_XYcXogQ.pgp Description: OpenPGP digital signature
Re: frame callbacks and sub_surfaces
Hi pq, I was thinking of a more full-featured example using sub surfaces with runtime positioning and z-order control. That aside I am having an interesting problem. In case of multiple surfaces, I only see the frame event for the last added surface. Surface A is behind B and C (tiled), none occluded. Here I get a frame callback for B. I'm using the commit pattern from B to Base. Surface B Surface A Base Adding sub surface C, with registered callbacks for B and C, I only see a frame callback for C. I'm using the commit pattern from C to Base. Surface C Surface B Surface A Base I don't touch the B callback when the C callback is added. Does anything stand out? Thanks, Joel
Re: frame callbacks and sub_surfaces
On Tue, 1 Nov 2022 20:08:10 -0700 Joel Winarske wrote: > Thanks for the clarification. Much appreciated. > > I'm interested in implementing a sub-surface example. Is a MR/PR of > interest? To which repository, and what do you want to demonstrate with it? E.g. https://gitlab.freedesktop.org/wayland/weston/-/blob/main/clients/subsurfaces.c exists already. Wayland repository can take documentation explaining all that better, but I'm not sure examples are in scope there. Maybe wayland-utils could have test programs better than weston repository, but I don't know about examples. Maybe others have ideas? Unless for special reasons, one should use a ready-made toolkit instead of programming apps directly for Wayland anyway. Thanks, pq pgp1hnguVzO8x.pgp Description: OpenPGP digital signature
Re: frame callbacks and sub_surfaces
Thanks for the clarification. Much appreciated. I'm interested in implementing a sub-surface example. Is a MR/PR of interest? Thanks, Joel On Tue, Nov 1, 2022 at 1:53 AM Pekka Paalanen wrote: > On Mon, 31 Oct 2022 10:14:42 -0700 > Joel Winarske wrote: > > > Thank you for the enlightenment! > > > > Adding the ordered commit calls was the missing link. > > > > Do the commit calls need to happen based on the active Z-order, or based > on > > the order of surface creation? > > They need to be ordered by sub-surface relationships, i.e. what is the > parent surface for a sub-surface. > > Z-order is completely irrelevant here. Also wl_surface creation order > is irrelevant. What is relevant is what you set as the parent > wl_surface in wl_subcompositor.get_subsurface request. > > You can create a sub-surface tree in any order by creating the > wl_subsurface objects in any order. The relevant thing is the final > parent surface <-> sub-surface association graph (actually a tree) when > you start doing updates (commits) to the wl_surfaces. > > > Thanks, > pq >
Re: frame callbacks and sub_surfaces
On Mon, 31 Oct 2022 10:14:42 -0700 Joel Winarske wrote: > Thank you for the enlightenment! > > Adding the ordered commit calls was the missing link. > > Do the commit calls need to happen based on the active Z-order, or based on > the order of surface creation? They need to be ordered by sub-surface relationships, i.e. what is the parent surface for a sub-surface. Z-order is completely irrelevant here. Also wl_surface creation order is irrelevant. What is relevant is what you set as the parent wl_surface in wl_subcompositor.get_subsurface request. You can create a sub-surface tree in any order by creating the wl_subsurface objects in any order. The relevant thing is the final parent surface <-> sub-surface association graph (actually a tree) when you start doing updates (commits) to the wl_surfaces. Thanks, pq pgpKVUvHfgAiH.pgp Description: OpenPGP digital signature
Re: frame callbacks and sub_surfaces
Thank you for the enlightenment! Adding the ordered commit calls was the missing link. Do the commit calls need to happen based on the active Z-order, or based on the order of surface creation? Thanks again, Joel
Re: frame callbacks and sub_surfaces
On Wed, 26 Oct 2022 20:56:14 -0700 Joel Winarske wrote: > When using sub_surfaces what is the expected behavior for frame callbacks > on a given surface? Hi, frame callbacks will trigger at the compositor's discretion after the wl_surface update with that frame callback request is applied, and if the wl_surface is mapped. A wl_surface update is applied on wl_surface.commit, unless that is postponed by some other extension, e.g. the wl_surface is a sub-surface in synchronized mode, in which case the update gets applied when the next parent wl_surface update committed after the sub-surface update gets applied. > Say I have the following: > > 1. base surface > 2. xdg surface referencing base surface > 3. wl surface A > 4. subsurface from a and base surface (default settings - none applied) > 5. wl surface B (set for sync) > 6. subsurface from wl surface B and wl surface A (above/sync setting) In other words, you have: - wl_surface "base", e.g. a top-level - wl_surface "A" is a sub-surface of "base", synchronized (default by the spec) - wl_surface "B" is a sub-surface of "A", synchronized Above/below makes no difference for this, unless it causes one of the wl_surfaces to be fully occluded. Fully occluded wl_surfaces might not trigger frame callbacks, because the content would not be seen anyway. > I find if I use wl_callback_add_listener using "surface A" when working > with "surface B" I get frame event callbacks of "surface A". If I use > wl_callback_add_listener with "surface B" I never see a frame callback. Do > I need to explicitly set the state of each subsurface in the stack to > match, and not rely on "default settings"? > > I tried setting "subsurface from B and surface B" as de-sync and I > experienced no change in behavior. > > I am at the point of mocking up a minimum repro case to exercise this > further. I'm hoping someone can enlighten me. I did not fully understand what your program is doing, so it's hard to say. The exact sequence of requests is crucial. Mind, that for frame callbacks to trigger, the wl_surface must be mapped first. If you ask for a frame callback, that frame callback will trigger when the compositor thinks it's a good time to draw again. Setting a frame callback is "double-buffered state", which means that for non-sub-surfaces you must send wl_surface.commit before the wl_surface.frame request will be acted on. On synchronized sub-surfaces, you will need a wl_surface.commit on the sub-surface first, *and* a wl_surface.commit on the parent surface next. It's actually recursive, so if the parent surface is a synchronized sub-surface for another wl_surface, then that other wl_surface needs a commit after the earlier ones as well. So in your case with the surfaces base -> A -> B You need this sequence to be able to get a frame callback triggered on wl_surface B: B.frame(cb) B.commit() A.commit() base.commit() And also all three surfaces must be already mapped or become mapped in that sequence. set_desync() is specified to apply immediately, so this should work too: B.set_desync() B.frame(cb) B.commit() But it is still conditional on all three surfaces getting mapped. A sub-surface cannot be visible unless all its ancestors are visible too. A surface that is not visible (not mapped, or is fully occluded) likely does not trigger frame callbacks. Thanks, pq pgpNI_Vmd0BgO.pgp Description: OpenPGP digital signature
