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

[Hyungwon Hwang]

Hello,
  2015년 12월 07일 17:17, Pekka Paalanen wrote:
> On Sat, 5 Dec 2015 11:09:21 +0900
> "hyungwon.hwang7" <hyungwon.hwang7 at gmail.com> wrote:
>
>> 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.
>
> Ok.
>
>> 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.
>
> Aha, it seems I have misunderstood what you mean.
>
> I have all the time assumed, that when you talk about seeing through
> fullscreen windows, that transparency will come  from the client (alpha
> channel with non-1.0 values). This is the case I have been arguing that
> it serves no practical purpose and is not worth the trouble
> implementing.
>
> We have to make a clear disctinction between transparency from the
> alpha channel as set by a client vs. the compositor doing tricks (the
> user controlled surface opacity parameter).
>
> As far as the spec goes, compositors are ultimately free to choose how
> they are going present surfaces, e.g. on the walls a first-person 3D
> world.
>
> It seems the topic here no longer has anything to do with the original
> thread [1].
>
>
> FYI, I do not like the user-controlled window opacity feature. It
> currently cannot work right with sub-surfaces, and the black surface
> case is equivalent to a sub-surface. We would need an intermediate
> composite of the compound window to be able to apply window opacity
> properly as a second step. I feel that implementing that costs too much
> in work, runtime, and maintenance at the moment.
>
>>> 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".
>
> This assumption came from the original thread [1], where the underlying
> problem related to the black surface was about switching activity
> between two windows, controlled by the clients instead of the user.
>
> It sounded like in that case the black surface was not correcly removed
> in all cases. Now I realize that that has nothing to do with your case.
>
>> 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?
>
> Sounds like a Weston bug, yes. The black surface is destroyed and
> re-created on-demand, so probably some of the creation paths forget to
> set the opacity. Or rather, never adjusted opacity, because I don't
> think anyone considered that feature before.
>
> In fact, an equally acceptable and possibly simpler solution would be
> to just disable the user opacity control for fullscreen surfaces. It
> would also be more correct, depending on how you would want opacity to
> apply. Third party desktop shells are free to implement friendlier
> features while we'd like to simplify rather than complicate the desktop
> shell in Weston itself. User controlled opacity has no obvious
> connection to demostrating Wayland protocols, so in that sense it is
> (nowadays) useless in Weston according to Weston's stated goals.

Regarding to the stated goals of Weston, I know that you're one of the 
men who contributed Weston so much and know a lot related it, and if you 
think like that, I also agree with that. Also, for some H/W limitation 
and other hassles, I agree that just disabling this function in 
fullscreen seems one of good solutions. Let's just drop it.

Thanks for your comment and kind explanation before.

Best regards,
Hyungwon Hwang

>
> But it is also a bug that was never discussed in the original thread [1]
> about the black surface until you. From my recollection of at least
> what I have understood, before you no-one had considered the user
> controlled window opacity feature, as it is not controllable from
> clients.
>
>
>>>>> 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
>
> Thanks,
> pq
>