[PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode

[Hyungwon Hwang]

Hello Bill Spizak,

On 2015년 12월 05일 00:46, Bill Spitzak wrote:
> On 12/04/2015 12:14 AM, Pekka Paalanen wrote:
>> On Thu, 3 Dec 2015 14:18:54 -0800
>> Bryce Harrington <bryce at osg.samsung.com> wrote:
>>
>>> On Thu, Dec 03, 2015 at 10:33:27PM +0900, Hyungwon Hwang wrote:
>>>> This patch changes the alpha value of black view in fullscreen mode,
>>>> when the applications opacity changes.
>>>>
>>>> Signed-off-by: Hyungwon Hwang <hyungwon.hwang7 at gmail.com>
>>>> ---
>>>> This patch is incomplete, and just a proof of concept. But I want to
>>>> make this patch as the starting point of discussion related the opacity
>>>> in fullscreen mode [1]. I tested it with weston-fullscreen.
>>>
>>> Thanks for sending this as an RFC, as a follow up to the earlier
>>> discussion with pq.  I notice some of the points he had raised in that
>>> discussion (e.g. avoiding alpha for letterbox edges, etc.) aren't
>>> being addressed.  In technical terms this patch doesn't look bad but you
>>> might include a discussion of how the remaining problems would be
>>> handled?
>>
>> FWIW, I do think that changing the opacity of the black surface like
>> this is a totally wrong approach to any problem.
>>
>> Either the opaque black borders exist or they do not. They are realized
>> by either a single black surface behind the window like currently, or
>> several black surfaces around the window. When the black borders must
>> not be drawn, the black surface(s) must be destroyed (and re-created
>> on-demand).
>
> If the intention is to make an otherwise-opaque window uniformly
> transparent, this is not going to work right.
>
> Say you wish to make the window 50% transparent. If the background color
> of a pixel is B and the window color is A, the desired result is
> B/2+A/2. However if you composite 50% opaque black over the background,
> you get B/2, and then if you composite the window over that with 50% you
> get B/4+A/2.
>
> You could instead do an additive composite of the window over the black
> (ie for alpha a, instead of doing B(1-a)+Aa, do B+Aa. However you have
> to special-case that in the composite stack.
>
> My feeling is that making the black be a "surface" is a mistake, it
> should instead be an aspect of the compositing. When the compositor
> composites in a full-screen surface, it also draws up to 4 black
> rectangles to fill the area between the surface and the edge of the
> screen. Instead of a black surface in the stack, there is a flag on the
> surface indicating this is wanted.

Yes. That's right. I would be exactly what I wanted. But as Pekka said, 
that kind of approach would make a problem in using kernel DRM plane. I 
also agreed with that, and wanted know how Weston should be implemented 
related with this issue. So before investigate more, I just sent this 
patch as RFC. Now I found that what I wanted to know, and I decided to 
drop it.

I really appreciate your review and comment.

Best regards,
Hyungwon Hwang

>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel