On Tue, 01 Dec 2015 14:27:40 +0900 Hyungwon Hwang <human.hw...@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
pgpYphAR_G7E9.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
