Hi,
On Mon, 24 Jun 2019 at 09:00, Jonas Ådahl wrote:
> On Fri, Jun 21, 2019 at 05:35:35PM -0700, Jasper St. Pierre wrote:
> > To be clear, the patch does break backwards compatibility with compositor
> > behavior -- it only weakens a guarantee by saying that transparent
> > fullscreen content is
On Fri, Jun 21, 2019 at 05:35:35PM -0700, Jasper St. Pierre wrote:
> 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.
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.
However, it does mean that clients might not get the output they desire
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
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
On Wed, Jun 19, 2019 at 01:35:42PM -0400, Drew DeVault wrote:
> Compositors are free to render surfaces at their discretion. This
> change clarifies that for xdg-shell's fullscreen surfaces.
> ---
> This point has been a recurring cause for frustration in Sway
> development, as users expect
