Hello,
2015년 12월 07일 17:17, Pekka Paalanen wrote:
On Sat, 5 Dec 2015 11:09:21 +0900
"hyungwon.hwang7" <hyungwon.hwa...@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 <br...@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.hwa...@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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
