[PATCH] xdg-shell: remove constraints for fullscreen

[Michael Blumenkrantz]

Hi,

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.

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.


Regards,
Mike

On Fri, 21 Jun 2019 14:32:34 -0400
"Drew DeVault" <sir at cmpwn.com> wrote:

> On Wed Jun 19, 2019 at 10:41 PM Jonas Ådahl wrote:
> > This changes the semantics in a non-backward compatible way; clients
> > relying on the currently defined behavior would break, so I'll have to
> > nack this change. You'd have to add a `set_fullscreen_translucent` or
> > something like that if the described behavior is needed.  
> 
> To re-use an argument that was brought up in the xdg-decoration
> discussion: compositors are just going to do whatever they want here,
> and this sets up expectations accordingly. Wayfire already disregards
> this clause, and consider this an announcement of Sway's intentions do
> to the same.
> 
> In any case, I don't think this grossly affects the behavior clients
> have come to rely on. I sought some feedback on this patch privately
> before posting it to consider these concerns upfront. The main use-case
> for the original wording was found to be media players which rely on
> this behavior for letterboxing when the aspect ratio between the output
> and the video differs - which is addressed in the proposed wording.
> 
> Additionally, the original wording never made any promises as to the
> relationship between the fullscreened surface and the output its shown
> on. One notable example is that the unreliability of wl_output's
> width/height specifications forces (correctly so) users to continue to
> use configure events to communicate the desired size. This is especially
> necessary with non-traditional outputs like VR headsets. Implementation
> details like direct scan-out, which is only possible given the
> constraints in the original wording, aren't actually guaranteed - but
> are not ruled out by the new wording.
> 
> What do you think? Does that rationale make more sense?
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel