<div dir="auto">To be clear, the patch does break backwards compatibility with compositor behavior -- it only weakens a guarantee by saying that transparent fullscreen content is undefined. Existing compositor behavior is still allowed.<div dir="auto"><br></div><div dir="auto">However, it does mean that clients might not get the output they desire under new rules. It also does not make any new guarantees for a client -- a fullscreen transparent terminal might show surfaces underneath, or it might not. That hardly seems useful to me from a client perspective.</div><div dir="auto"><br></div><div dir="auto">That said, adding a new request does not seem like a good solution to me -- if the user presses a compositor key shortcut, should the app be in transparent or opaque fullscreen mode? It might make sense to have a special "set_fullscreen_blend_mode" that clients can use to configure their fullscreen appearance in all cases. I do not imagine this will change often, so it likely does not need to be a state. </div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 21, 2019, 8:43 PM Michael Blumenkrantz <<a href="mailto:michael.blumenkrantz@gmail.com">michael.blumenkrantz@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Some compositors and client toolkits do rely on the existing wording. Occlusion culling is used for (obvious) performance reasons in fullscreen cases. If the fullscreen surface is not opaque, clients can still rely on the compositor's handling of fullscreen states using the current wording and prioritize resources for this fullscreen surface even if there are other surfaces which are visible behind it. This is especially true for embedded cases.<br>
<br>
Given that releases and products have already shipped that rely on this language, and that the terminology and language used here is a core functionality of the feature, it absolutely cannot be changed.<br>
<br>
<br>
Regards,<br>
Mike<br>
<br>
On Fri, 21 Jun 2019 14:32:34 -0400<br>
"Drew DeVault" <<a href="mailto:sir@cmpwn.com" target="_blank" rel="noreferrer">sir@cmpwn.com</a>> wrote:<br>
<br>
> On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote:<br>
> > This changes the semantics in a non-backward compatible way; clients<br>
> > relying on the currently defined behavior would break, so I'll have to<br>
> > nack this change. You'd have to add a `set_fullscreen_translucent` or<br>
> > something like that if the described behavior is needed.  <br>
> <br>
> To re-use an argument that was brought up in the xdg-decoration<br>
> discussion: compositors are just going to do whatever they want here,<br>
> and this sets up expectations accordingly. Wayfire already disregards<br>
> this clause, and consider this an announcement of Sway's intentions do<br>
> to the same.<br>
> <br>
> In any case, I don't think this grossly affects the behavior clients<br>
> have come to rely on. I sought some feedback on this patch privately<br>
> before posting it to consider these concerns upfront. The main use-case<br>
> for the original wording was found to be media players which rely on<br>
> this behavior for letterboxing when the aspect ratio between the output<br>
> and the video differs - which is addressed in the proposed wording.<br>
> <br>
> Additionally, the original wording never made any promises as to the<br>
> relationship between the fullscreened surface and the output its shown<br>
> on. One notable example is that the unreliability of wl_output's<br>
> width/height specifications forces (correctly so) users to continue to<br>
> use configure events to communicate the desired size. This is especially<br>
> necessary with non-traditional outputs like VR headsets. Implementation<br>
> details like direct scan-out, which is only possible given the<br>
> constraints in the original wording, aren't actually guaranteed - but<br>
> are not ruled out by the new wording.<br>
> <br>
> What do you think? Does that rationale make more sense?<br>
> _______________________________________________<br>
> wayland-devel mailing list<br>
> <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">wayland-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a></blockquote></div>