On Wed, 30 Sep 2015 09:50:09 -0700 Bill Spitzak <spit...@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....@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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > >
pgpL06bJ45KOz.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
