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

[hyungwon.hwang7]

Hello Pekka,

On 2015년 12월 04일 17:14, 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 there are obvious bugs with the on-demand realization of the black
> surface, like I understood from the comments that there might be,
> fixing those would not be controversial.
>
> The real question here is, what use case is there for a fullscreen
> window to be semi-transparent?
>
> Should the definition of fullscreen include the assumption of not being
> able to see through the window?
>
> The answer to that question must affect shell protocol specification,
> or you will get varying implementations between compositors. So, the
> proper starting point for that discussion is to look at the shell
> protocol specifications.

I found the spec in 
http://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shell. Again, 
I am new to wayland. We are seeing the same document, right?The spec 
does not break anything in wl_shell_surface::fullscreen_method. The 
protocol describe what should be happen when the surface output and the 
output size differ. With this change, it doesn't affect that behavior. 
It just makes the users to be able to adjust the opacity of the black 
view behind the surface of fullscreen application. For now, when the 
user intentionally adjust the opacity of application in fullscreen mode, 
only the application surface is affected. So the black view appears as 
the surface becomes transparent. But with this change, the behind 
surfaces will appears because the black view's alpha is synced with the 
application's alpha. In the discussion, we talked about 3 use cases,
1. Fullscreen media player
2. Fullscreen game
3. Fullscreen terminal

For 1 & 2, I think that the user probably would not want to make the app 
transparent in most cases. In these cases, the behavior related with 
black border is same as it is. But even he wants intentionally, the 
application itself and the black border around the application would be 
transparent as he wants.

For 3, some people including me like transparent fullscreen terminal. 
But for now, it is not available because of opaque black view behind.

If it does not break something in spec, I think that this change will 
give the users more options to use Weston for their purpose.

>
> Also, xdg_shell specification is very different to that of wl_shell
> right now. Xdg_shell requires that the window size matches the output
> size, which pushes the issue of black borders to the client. So in the
> current state of protocol development, questions here apply pretty much
> only to wl_shell.
>
> What Weston currently implements wrt. to the black surface may not be
> correct for all possible use cases, but I claim that the intention is
> correct for the cases where the window size does not match the output
> size, as specified in wl_shell spec.
>
> Mind, I will outright refuse all use cases where you use opacity and
> input region manipulations to just "switch windows" from client side.
>

I think that there are some misunderstanding about "switching windows". 
I am not a English native. So I wrote the sentences unclearly. If it 
was, I am sorry about that. Anyway, I meant to say that is there any 
reason to reset the opacity of an application which the user 
intentionally adjusted, when the user just switch to another application 
and return back? I thougt that it was weston bug, isn't it?

Thanks for your comment, Pekka.

Best regards,
Hyungwon Hwang

>
> Thanks,
> pq
>
>>> 1. Changing the opacity in normal mode.
>>> 2. Changing the opacity in fullscreen mode.
>>> 3. Changing the opacity in fullscreen mode, but the content is smaller
>>> then output.
>>> 4. After 1 & 2, switch to another application.
>>> 5. After 3, switch to another application.
>>>
>>> In case of 1 ~ 4, it works fine. But in case of 5, the opacity does
>>> not be kept, and it must be fixed. I think that it is also related another
>>> issue I stated in PS below.
>>>
>>> I want to discuss about what stance Weston will be on with this issue
>>> : When opacity changes in fullscreen mode, which surface's opacity should
>>> be affected.
>>>
>>> PS. As I made this patch, I found that the opacity resets when the user switch
>>> to another application irrespective of fullscreen. It also seemed a little
>>> odd to me.
>>>
>>> Best regards,
>>> Hyungwon Hwang
>>>
>>> [1]
>>> http://lists.freedesktop.org/archives/wayland-devel/2015-December/025859.html