black surface in desktop shell fullscreen mode

[Pekka Paalanen]

On Wed, 30 Sep 2015 09:50:09 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> If you are actually destroying the fullscreen surface, then this sounds
> like a bug.

Yes. It all depends on what "hide" means in Wayland protocol terms with
the applications in question.

> The inability to make a fullscreen surface partially-transparent is on
> purpose, though it might be considered a design error.

Yes, it is on purpose, for the use cases that actually want black bars
when the window is smaller than the output size.

A fullscreen window with show-through parts is kind of an odd concept,
IMHO. For maximized I might understand.

All use cases that come to my mind for show-through fullscreen windows
are hacks around how Wayland works, trying to do things one just should
not attempt to do. They are not meant to work.

> I believe Weston is
> trying to pad out the buffer (which may be the wrong shape or size) to fill
> the screen. It could do this by adding black rectangles around it, so
> transparency still works, but instead it is putting a black fullscreen
> rectangle behind it.

Indeed.

> Possibly better would be to replicate the edge pixels
> of the buffer to fill the screen, which would give the client an easy way
> to control the color and transparency of the fill area. Also any rule for
> how this is done needs to apply to normal windows for any cases where the
> client does not produce a buffer that is the size/shape the compositor
> wants, this occurs in tiled window managers.

Pad repeat? That requires application awareness to actually set the
edge pixels. This may be very hard e.g. for video players that just
push the decoded video frame out to screen, and expect the compositor
to add black bars as necessary. You are often dealing with
hardware-acceleration capable buffers, which causes all kinds of
complications.

So, pad repeat would need to be a client opt-in feature. This means new
protocol. Seems like a huge detour to just allow "show through for a
fullscreen window". It would be much simpler to add a flag that would
achieve the show-through. Is this actually a good idea, I don't know. I
have a feeling that some people are trying to work around Wayland
rather than using it the way it is meant to.

Another essential problem with pad repeat is that it forces the
compositor to composite, removing the possibility of direct scanout,
which for fullscreen apps is generally a very important optimization.

The black blanket surface behind the window OTOH allows for direct
scanout. If black bars are not visible and the client buffer is
completely opaque, it is possible to scan it out without composition by
rendering. Even if black bars are visible, the client buffer could be
scanned out on an overlay plane, or if the hardware supports it, it
could be scanned out directly as the primary plane of the crtc and
letting the scanout hardware fill in the black bars. In all cases, the
black surface below would never change, so new video frames would not
cause new rendering in the compositor when direct scanout is possible.


Thanks,
pq

> On Wed, Sep 30, 2015 at 1:35 AM, zou lan <nancy.lan.zou at gmail.com> wrote:
> 
> > Hi all
> >
> > As I known, when a window is fullscreen, desktop shell will create a black
> > surface after it. If the window is transparent later, it shows a black
> > screen. But the app developers maybe except it to be hide.
> >
> > Just take QWindow function hide for example, app1 start app2, then app2
> > call hide, it excepts to show app1, but it shows the black surface of app2.
> >
> >
> >
> >    - Does the desktop shell doesn't support set fullscreen surface to be
> >    transparent?
> >    - Thank you.
> >
> > Best Regards
> > Nancy
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151001/8ce1b53a/attachment.sig>