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 <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 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
