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

[Guillermo Rodriguez]

El mar., 28 ene. 2020 a las 12:55, Pekka Paalanen
(<ppaalanen at gmail.com>) escribió:
>
> On Mon, 27 Jan 2020 16:13:41 +0100
> Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
>
> > Hi,
> >
> > El lun., 27 ene. 2020 a las 14:21, Pekka Paalanen
> > (<ppaalanen at gmail.com>) escribió:
> > >
> > > On Mon, 27 Jan 2020 12:58:13 +0100
> > > Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
> > >
> > > > El lun., 27 ene. 2020 a las 12:53, Pekka Paalanen
> > > > (<ppaalanen at gmail.com>) escribió:
> > > > >
> > > > > On Mon, 27 Jan 2020 12:36:27 +0100
> > > > > Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
> > > > >
> > > > > > Thank you for your answer. This is an embedded fullscreen application, so no
> > > > > > window management.
> > > > >
> > > > > Fullscreen is one of the modes where you need to be careful with your
> > > > > window size and synchronise correctly to obey the compositor's demands.
> > > >
> > > > Can you elaborate on this?
> > >
> > > Hi,
> > >
> > > the xdg-shell extension suite has some rules on when the client must
> > > obey compositor constraints and when it is free to pick any window size
> > > it wants.
> > >
> > > I am assuming that you are using the xdg-shell extension suite for
> > > window management. If you are using some other extension for window
> > > management, that changes things. In any case, you must be using some
> > > window management extension, because otherwise the window will not
> > > appear on screen.
> >
> > I'm using wl_shell.
>
> Ok, the deprecated one. Even wl_shell has
> wl_shell_surface.set_fullscreen you could use. I must note though that
> the special features of fullscreen method and preferred framerate are
> not implemented in Weston.
>
> If possible, I would recommend migrating to the xdg-shell extension
> suite which is maintained both protocol and implementation wise.
>
> > > > btw I said fullscreen but this is actually a toplevel shell surface
> > > > with the same
> > > > size as the current video mode (so that it occuppies the whole screen).
> > >
> > > That is not fullscreen but a floating window with a peculiar size.
> > > Position of the window could be anywhere, and does not prevent UI
> > > components like desktop panels from displacing it or showing on top of
> > > it.
> >
> > Yes, that's why I clarified that it is not really a fullscreen
> > surface, but a toplevel surface with the dimensions of the screen.
> > (I know that position of the window is not specified by the protocol,
> > but Weston is always placing the surface at 0,0)
>
> That is an accident you should not rely on. Weston generally uses
> random() to position floating windows at the moment, but currently does
> attempt to keep the whole window visible.
>
> > Also this is an embedded system where there are no other components
> > such as desktop panels...
>
> Sure, but you risk it breaking on a Weston update if you don't use the
> protocol to ensure you get what you want.
>
> IIRC the user can use a key-mouse-combination to force-move or rotate
> any floating window but not a fullscreen window.

Just tried this but found that fullscreen windows seem to be made
fully opaque (black surface behind), which does not work for me.
I have two "pseudo full screen" windows, one is stacked on top of the
other, and the topmost window needs to have transparent areas.
So I guess I will need to stick with a toplevel surface and rely on
Weston keeping the whole window visible..

BR,

Guillermo Rodriguez Garcia