Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
Hello, 2015년 12월 07일 17:17, Pekka Paalanen wrote: On Sat, 5 Dec 2015 11:09:21 +0900 "hyungwon.hwang7"wrote: Hello Pekka, On 2015년 12월 04일 17:14, Pekka Paalanen wrote: On Thu, 3 Dec 2015 14:18:54 -0800 Bryce Harrington 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 --- 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
Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
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 Harringtonwrote: 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 --- 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
On Sat, 5 Dec 2015 11:09:21 +0900 "hyungwon.hwang7"wrote: > Hello Pekka, > > On 2015년 12월 04일 17:14, Pekka Paalanen wrote: > > On Thu, 3 Dec 2015 14:18:54 -0800 > > Bryce Harrington 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 > >>> --- > >>> 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
Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
On 12/04/2015 12:14 AM, Pekka Paalanen wrote: On Thu, 3 Dec 2015 14:18:54 -0800 Bryce Harringtonwrote: 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 --- 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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
On Mon, Dec 7, 2015 at 12:17 AM, Pekka Paalanenwrote: > > 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. > In fact it fails even in this case with the black background. A 50% opaque window composited atop a 50% opaque black is not the same result as just a 50% opaque window. In fact he will get a much closer simulation of the desired result if the black surface was removed when the surface is made transparent. Pixels inside the surface will be correct, and if it happens to fill the screen then all pixels will be correct. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
On Thu, 3 Dec 2015 14:18:54 -0800 Bryce Harringtonwrote: > 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 > > --- > > 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. 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. 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 pgpu5FBMkDNLv.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
Hello Pekka, On 2015년 12월 04일 17:14, Pekka Paalanen wrote: On Thu, 3 Dec 2015 14:18:54 -0800 Bryce Harringtonwrote: 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 --- 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,
Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
Hello Bryce, On 2015년 12월 04일 07:18, Bryce Harrington 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--- 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? OK. Next time I send RFC, I will clear my opinion. Thanks for your comment. Also, don't forget to use your samsung address when sending patches (assuming this is for work). It's my hobby at home. Best regards, Hyungwon Hwnag 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 desktop-shell/shell.c | 36 +++- 1 file changed, 23 insertions(+), 13 deletions(-) diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index 780902d..418c66f 100644 --- a/desktop-shell/shell.c +++ b/desktop-shell/shell.c @@ -2767,7 +2767,7 @@ black_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy); static struct weston_view * create_black_surface(struct weston_compositor *ec, struct weston_surface *fs_surface, -float x, float y, int w, int h) +float x, float y, int w, int h, float alpha) { struct weston_surface *surface = NULL; struct weston_view *view; @@ -2783,11 +2783,12 @@ create_black_surface(struct weston_compositor *ec, weston_surface_destroy(surface); return NULL; } + view->alpha = alpha; surface->configure = black_surface_configure; surface->configure_private = fs_surface; weston_surface_set_label_func(surface, black_surface_get_label); - weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1); + weston_surface_set_color(surface, 0.0, 0.0, 0.0, alpha); pixman_region32_fini(>opaque); pixman_region32_init_rect(>opaque, 0, 0, w, h); pixman_region32_fini(>input); @@ -2812,7 +2813,8 @@ shell_ensure_fullscreen_black_view(struct shell_surface *shsurf) shsurf->surface, output->x, output->y, output->width, -output->height); +output->height, +shsurf->view->alpha); weston_view_geometry_dirty(shsurf->fullscreen.black_view); weston_layer_entry_remove(>fullscreen.black_view->layer_link); @@ -4717,10 +4719,24 @@ resize_binding(struct weston_pointer *pointer, uint32_t time, } static void +do_adjust_alpha(struct weston_view *view, wl_fixed_t value) { + float step = 0.005; + + view->alpha -= wl_fixed_to_double(value) * step; + + if (view->alpha > 1.0) + view->alpha = 1.0; + if (view->alpha < step) + view->alpha = step; + + weston_view_geometry_dirty(view); + weston_surface_damage(view->surface); +} + +static void surface_opacity_binding(struct weston_pointer *pointer, uint32_t time, uint32_t axis, wl_fixed_t value, void *data) { - float step = 0.005; struct shell_surface *shsurf; struct weston_surface *focus = pointer->focus->surface; struct weston_surface *surface; @@ -4734,15 +4750,9 @@ surface_opacity_binding(struct weston_pointer *pointer, uint32_t time, if (!shsurf) return; - shsurf->view->alpha -= wl_fixed_to_double(value) * step; - - if (shsurf->view->alpha > 1.0) - shsurf->view->alpha =
[PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
This patch changes the alpha value of black view in fullscreen mode, when the applications opacity changes. Signed-off-by: Hyungwon Hwang--- 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. 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 desktop-shell/shell.c | 36 +++- 1 file changed, 23 insertions(+), 13 deletions(-) diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c index 780902d..418c66f 100644 --- a/desktop-shell/shell.c +++ b/desktop-shell/shell.c @@ -2767,7 +2767,7 @@ black_surface_configure(struct weston_surface *es, int32_t sx, int32_t sy); static struct weston_view * create_black_surface(struct weston_compositor *ec, struct weston_surface *fs_surface, -float x, float y, int w, int h) +float x, float y, int w, int h, float alpha) { struct weston_surface *surface = NULL; struct weston_view *view; @@ -2783,11 +2783,12 @@ create_black_surface(struct weston_compositor *ec, weston_surface_destroy(surface); return NULL; } + view->alpha = alpha; surface->configure = black_surface_configure; surface->configure_private = fs_surface; weston_surface_set_label_func(surface, black_surface_get_label); - weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1); + weston_surface_set_color(surface, 0.0, 0.0, 0.0, alpha); pixman_region32_fini(>opaque); pixman_region32_init_rect(>opaque, 0, 0, w, h); pixman_region32_fini(>input); @@ -2812,7 +2813,8 @@ shell_ensure_fullscreen_black_view(struct shell_surface *shsurf) shsurf->surface, output->x, output->y, output->width, -output->height); +output->height, +shsurf->view->alpha); weston_view_geometry_dirty(shsurf->fullscreen.black_view); weston_layer_entry_remove(>fullscreen.black_view->layer_link); @@ -4717,10 +4719,24 @@ resize_binding(struct weston_pointer *pointer, uint32_t time, } static void +do_adjust_alpha(struct weston_view *view, wl_fixed_t value) { + float step = 0.005; + + view->alpha -= wl_fixed_to_double(value) * step; + + if (view->alpha > 1.0) + view->alpha = 1.0; + if (view->alpha < step) + view->alpha = step; + + weston_view_geometry_dirty(view); + weston_surface_damage(view->surface); +} + +static void surface_opacity_binding(struct weston_pointer *pointer, uint32_t time, uint32_t axis, wl_fixed_t value, void *data) { - float step = 0.005; struct shell_surface *shsurf; struct weston_surface *focus = pointer->focus->surface; struct weston_surface *surface; @@ -4734,15 +4750,9 @@ surface_opacity_binding(struct weston_pointer *pointer, uint32_t time, if (!shsurf) return; - shsurf->view->alpha -= wl_fixed_to_double(value) * step; - - if (shsurf->view->alpha > 1.0) - shsurf->view->alpha = 1.0; - if (shsurf->view->alpha < step) - shsurf->view->alpha = step; - - weston_view_geometry_dirty(shsurf->view); - weston_surface_damage(surface); + do_adjust_alpha(shsurf->view, value); + if (shsurf->fullscreen.black_view) + do_adjust_alpha(shsurf->fullscreen.black_view, value); } static void -- 1.9.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] [RFC] desktop-shell: change the alpha of black view in fullscreen mode
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> --- > 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? Also, don't forget to use your samsung address when sending patches (assuming this is for work). > 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 > > desktop-shell/shell.c | 36 +++- > 1 file changed, 23 insertions(+), 13 deletions(-) > > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c > index 780902d..418c66f 100644 > --- a/desktop-shell/shell.c > +++ b/desktop-shell/shell.c > @@ -2767,7 +2767,7 @@ black_surface_configure(struct weston_surface *es, > int32_t sx, int32_t sy); > static struct weston_view * > create_black_surface(struct weston_compositor *ec, >struct weston_surface *fs_surface, > - float x, float y, int w, int h) > + float x, float y, int w, int h, float alpha) > { > struct weston_surface *surface = NULL; > struct weston_view *view; > @@ -2783,11 +2783,12 @@ create_black_surface(struct weston_compositor *ec, > weston_surface_destroy(surface); > return NULL; > } > + view->alpha = alpha; > > surface->configure = black_surface_configure; > surface->configure_private = fs_surface; > weston_surface_set_label_func(surface, black_surface_get_label); > - weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1); > + weston_surface_set_color(surface, 0.0, 0.0, 0.0, alpha); > pixman_region32_fini(>opaque); > pixman_region32_init_rect(>opaque, 0, 0, w, h); > pixman_region32_fini(>input); > @@ -2812,7 +2813,8 @@ shell_ensure_fullscreen_black_view(struct shell_surface > *shsurf) >shsurf->surface, >output->x, output->y, >output->width, > - output->height); > + output->height, > + shsurf->view->alpha); > > weston_view_geometry_dirty(shsurf->fullscreen.black_view); > weston_layer_entry_remove(>fullscreen.black_view->layer_link); > @@ -4717,10 +4719,24 @@ resize_binding(struct weston_pointer *pointer, > uint32_t time, > } > > static void > +do_adjust_alpha(struct weston_view *view, wl_fixed_t value) { > + float step = 0.005; > + > + view->alpha -= wl_fixed_to_double(value) * step; > + > + if (view->alpha > 1.0) > + view->alpha = 1.0; > + if (view->alpha < step) > + view->alpha = step; > + > + weston_view_geometry_dirty(view); > + weston_surface_damage(view->surface); > +} > + > +static void > surface_opacity_binding(struct weston_pointer *pointer, uint32_t time, > uint32_t axis, wl_fixed_t value, void *data) > { > - float step = 0.005; > struct shell_surface *shsurf; > struct weston_surface *focus = pointer->focus->surface; > struct weston_surface *surface; > @@ -4734,15 +4750,9 @@ surface_opacity_binding(struct weston_pointer > *pointer, uint32_t time, > if (!shsurf) > return; > > - shsurf->view->alpha -= wl_fixed_to_double(value) * step; > - > - if (shsurf->view->alpha > 1.0) > - shsurf->view->alpha = 1.0; > - if (shsurf->view->alpha < step) > -