black surface in desktop shell fullscreen mode

[Pekka Paalanen]

On Tue, 01 Dec 2015 14:27:40 +0900
Hyungwon Hwang <human.hwang at samsung.com> wrote:

> Hello all,
> 
> Reading the mail thread, I tried to figure out the problem by myself.
> Until now, I couldn't find any reason to make fullscreen application
> totally opaque. As I found in git history, in my opinion, the author
> of fullscreen implementation just thought that fullscreen has black
> surface behind it.
> 
> IMHO, the fix could be fairly simple. Just remove "struct weston_view
> *black_view" from struct fullscree and the usages in the source. As I
> tested, it works fine. But I am new to weston and not familiar with
> weston testing, it needs more test and code analysis. Could you give
> your opinion about it?

The original reason the black surface exists at all is to get black
borders as needed, when the window size does not match the output size.
This is mandated by the wl_shell.set_fullscreen where some of the
options require black borders.

The intended use case for fullscreen windows are video players, games,
etc. which want to cover as much screen space as possible and not show
anything else. Opaqueness is a requirement for composite-bypass which
makes the presentation efficient. When writing the wl_shell spec and
the implementation, no-one expected that one might want to see through
the fullscreen window to other windows and the desktop. Also, at the
time there was no efficient method for a client to provide its own
black surface, this will come with the scaler/viewport protocol
extension.

Rather than assuming the surface is opaque, we could check the opaque
region on the wl_surface, and make the black surface conditional on
that and the fullscreen_method. I think that could be reasonable, if
there are people willing to write the patches and review them.

Furthermore when the window size does not match the output size, black
borders are required, and the surface is not opaque, the black borders
need to be constructed from two or four black surfaces. I doubt anyone is
interested in implementing that, so this corner case could be left as
is and assumed in such situations that the surface is opaque even if
it's not marked as such.

In any case, wl_shell requires black borders in some cases, so you
cannot just remove the black surface implementation. Xdg_shell might be
different as it can point to the scaler/viewport extension and tell
clients to implement their own black surfaces as needed.

Also note, that splitting the black surface into several surfaces or
removing it can have adverse effects on performance, once we start
using hardware overlay planes by default. If there is a single, opaque
black surface and on top of it just one other surface plus possibly a
cursor, then it is easy for the DRM-backend to put the black surface on
the primary plane, the other surface (with real content) on an overlay
plane, and the cursor on a cursor plane. This will bypass compositing
completely, which means there is no composite rendering step in
presenting the application - it becomes a real zero-copy pipeline as
far as the compositor is concerned. This is important for efficient
video playback.

If the black surface is split into several surfaces, the backend would
need special code added to detect whether it could do what I described
above, it would not happen automatically as it would now, and the
backend would have to manufacture the output-sized black buffer by
itself in case the primary plane's buffer cannot be smaller than the
video mode.

Video players do not want to draw black borders into the video frame to
match the output size because of performance penalties, but they could
provide their own black surface as a sub-surface as needed. This would
be essentially the same as what the desktop shell now does
automatically, but require code in the player. Modern games probably
want to match the output size with a single opaque surface in all
cases, so those are less of a concern.


Rather than claiming how things must be, I hope I gave some rationale
on why things are like they are, and what we need to consider if we
were to change them.


There are two separate discussions going on in this thread:

1. The bug in Weston where unmapping a fullscreen surface
   does not tear down the black surface properly.

2. Whether the use of the black surface and opaqueness assumption are
   valid in the first place as implemented in Weston's desktop shell.

Discussion on 1 is purely technical and easy to handle. Discussion on 2
involves policy, use cases, optimizations, and opinions, and
implementing changes is a non-trivial amount of work. Therefore I'd
like to see those two discussions separated into new email threads.


Thanks,
pq
-------------- 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/20151201/78b0b4ab/attachment.sig>