Fullscreen window (Re: Thread safety when rendering on a separate thread)

[Pekka Paalanen]

On Thu, 30 Jan 2020 12:49:34 +0100
Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:

> El jue., 30 ene. 2020 a las 12:25, Pekka Paalanen
> (<ppaalanen at gmail.com>) escribió:
> >
> > On Thu, 30 Jan 2020 11:46:59 +0100
> > Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
> >  
> > > Just tried this but found that fullscreen windows seem to be made
> > > fully opaque (black surface behind), which does not work for me.  
> >
> > Yes, that is very intentional.
> >  
> > > I have two "pseudo full screen" windows, one is stacked on top of the
> > > other, and the topmost window needs to have transparent areas.  
> >
> > The same process or separate processes?
> >
> > The same client or separate clients?
> >
> > Usually that is managed by making one of the windows a sub-surface for
> > the other, but that only works within the same client.  
> 
> Yes, but this is not possible in my case. These are two separate
> applications; one of them (the "main" application) controls the other
> (a OSD style component which stays on top) by sending commands to it
> through a CLI.
> So I cannot easily make one window a sub-surface of the other.
> 
> >  
> > > So I guess I will need to stick with a toplevel surface and rely on
> > > Weston keeping the whole window visible..  
> >
> > That is very unfortunate. We cannot even attempt to keep that working
> > from upstream side. You are depending on luck for window positioning
> > and stacking order. Wouldn't a user hitting Mod+Tab or Alt+Tab already
> > break your setup?  
> 
> Well, there's no keyboard :-)
> 
> >
> > Do you prevent pointer and touch input to one of the windows completely
> > via input regions?  
> 
> Yes; the OSD app does not accept any input.
> 
> >
> > Sounds like fixing that properly could mean an architectural re-design
> > for your application.  
> 
> If that means combining the two applications into one -- I'd rather
> not do that; there are multiplea reasons why these are designed as
> independent applications.
> Ideally I should be able to find a way to setup Wayland to fit the
> requirements rather than the opposite (tweak the requirements to fit
> Wayland :-)

Right. Since this is now obviously not about a desktop use case anymore
but a quite a specialised use case with probably even a closed system,
you do not have to settle for the normal desktop extensions of Wayland.

The OSD is not a "normal desktop client", so it could use a different
Wayland extension for managing its window. I believe wlroots has some
extensions that could apply, and you can always write your own custom
extensions. Both have the caveat that you need to write the Weston
implementation as well. The benefit is that then you will have
guaranteed behaviour: the compositor knows what the OSD actually is and
has code to specifically keep it where it belongs.

Since the OSD probably does not interact with any other window
management, I think it might be possible to implement the protocol
extension as a downstream Weston plugin rather than hacking e.g.
desktop-shell/shell.c in weston.

If the OSD is actually fullscreen-sized right now but you only need a
sub-part of that area, meaning that most of the OSD window is completely
transparent, then with a suitable protocol extension you could avoid
having the completely transparent areas. Transparent areas still need
to be composited one way or another, so not having them could be a
a win in performance or power consumption.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200130/b0db38e7/attachment.sig>