New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xwayland: transparency in firefox windows #348

Closed
acrisci opened this Issue Oct 27, 2017 · 11 comments

Comments

Projects
None yet
6 participants
@acrisci
Copy link
Contributor

acrisci commented Oct 27, 2017

Firefox seems to show junk around the borders with drop shadows (depending on the GL clear color).

I think it is choosing the wrong visual depth. On rootston, it chooses a 24-bit depth but on weston it chooses a 32-bit depth for windows with drop shadows.

I know we support transparency on X11 windows for sure when they choose the correct depth. For instance, this program demonstrates that wlr-xwayland is capable of displaying windows with transparency.

Maybe it is copying this attribute from the parent (root window) which does not have an alpha channel. In that case, we might have to reparent the window to get Firefox to behave correctly.

@acrisci acrisci referenced this issue Oct 27, 2017

Merged

xwayland window manager fixes #331

4 of 5 tasks complete

@ddevault ddevault added this to the 1.0 milestone Dec 16, 2017

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Dec 27, 2017

I investigated this issue a little.

Firefox renders correctly in wlc. wlc uses the color depth to know if a surface has an alpha channel (weston and wlroots do the same). It uses this info to change the wl_surface format (https://github.com/Cloudef/wlc/blob/master/src/xwayland/xwm.c#L386, https://github.com/Cloudef/wlc/blob/f4ff049cc30242eec9f33af7129d2e2a2865fb5a/src/platform/render/gles2.c#L544). But in wlroots has_alpha is always false, so I'm not sure it's related to this issue (it seems that Firefox doesn't choose a 32-bit color depth, like @acrisci said). wlc does nothing special to set a particular visual ID/colormap to its root window, or to reparent client windows.

Weston uses a "frame" window. It's a window created when an xwayland window is mapped that has the same size as the client window. The frame window is set as the parent of the client window. The frame window has the colormap chosen in xwm_get_visual_and_colormap. I'm not sure if/why it's necessary to do this.

@acrisci

This comment has been minimized.

Copy link
Contributor

acrisci commented Dec 27, 2017

My theory (might be incorrect, just guessing).

I think there might be a COPY_FROM_PARENT somewhere that chooses the visual depth of the parent window. If the parent is root, it will choose the root visual depth which I think is 24. If it is reparented, it will choose the visual depth of the parent which we can set to 32.

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Dec 27, 2017

I still don't understand why it works on wlc and doesn't on wlroots. wlc uses xcb_composite_redirect_subwindows_checked but that doesn't change anything.

Choosing a 32-bit color depth for the root window hides all xwayland windows.

@ddevault

This comment has been minimized.

Copy link
Member

ddevault commented Dec 27, 2017

Choosing a 32-bit color depth for the root window hides all xwayland windows.

I think this is barking up the right tree. Disclaimer: I know next to nothing about X11.

@Ongy

This comment has been minimized.

Copy link
Contributor

Ongy commented Feb 15, 2018

xwininfo on the main window of firefox looks about the same between rootston on and sway.
The only difference is on the popup. So the parent of the main window shouldn't be the cause of this.

xwininfo of the root looks mostly equivalent as well.
The biggest difference I can make out atm. Is the different NET_SUPPORTED atoms.
Sway on wlc has a lot of them, while the ones on rootston are rather limited

_NET_SUPPORTED(ATOM) = _NET_WM_CM_S0, _NET_WM_PID, _NET_WM_NAME, _NET_WM_STATE, _NET_WM_STATE_FULLSCREEN, _NET_SUPPORTING_WM_CHECK, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_DESKTOP, _NET_WM_WINDOW_TYPE_DOCK, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_NOTIFICATION, _NET_WM_WINDOW_TYPE_COMBO, _NET_WM_WINDOW_TYPE_DND, _NET_WM_WINDOW_TYPE_NORMAL

vs

_NET_SUPPORTED(ATOM) = _NET_WM_STATE, _NET_ACTIVE_WINDOW, _NET_WM_MOVERESIZE, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ

@ddevault ddevault added the hackathon label Feb 26, 2018

@emersion emersion removed the hackathon label May 30, 2018

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Jul 8, 2018

Tried running xdpyinfo which prints info about visuals, they're almost the same in wlroots and in weston, the differences aren't very interesting.

diff --git a/home/simon/weston-xdpyinfo.log b/home/simon/wlroots-xdpyinfo.log
index b697a3af..ca843aa8 100644
--- a/home/simon/weston-xdpyinfo.log
+++ b/home/simon/wlroots-xdpyinfo.log
@@ -1,8 +1,8 @@
-name of display:    :2
+name of display:    :0
 version number:    11.0
 vendor string:    The X.Org Foundation
-vendor release number:    12000000
-X.Org version: 1.20.0
+vendor release number:    12099001
+X.Org version: 1.20.99.1
 maximum request size:  16777212 bytes
 motion buffer size:  256
 bitmap unit, bit order, padding:    32, LSBFirst, 32
@@ -17,8 +17,8 @@ supported pixmap formats:
     depth 24, bits_per_pixel 32, scanline_pad 32
     depth 32, bits_per_pixel 32, scanline_pad 32
 keycode range:    minimum 8, maximum 255
-focus:  PointerRoot
-number of extensions:    25
+focus:  None
+number of extensions:    24
     BIG-REQUESTS
     Composite
     DAMAGE
@@ -32,7 +32,6 @@ number of extensions:    25
     RANDR
     RECORD
     RENDER
-    SECURITY
     SHAPE
     SYNC
     X-Resource
@@ -48,7 +47,7 @@ default screen number:    0
 number of screens:    1
 
 screen #0:
-  dimensions:    1024x640 pixels (271x169 millimeters)
+  dimensions:    1600x900 pixels (423x238 millimeters)
   resolution:    96x96 dots per inch
   depths (7):    24, 1, 4, 8, 15, 16, 32
   root window id:    0x39c
@@ -58,9 +57,10 @@ screen #0:
   default number of colormap cells:    256
   preallocated pixels:    black 0, white 16777215
   options:    backing-store WHEN MAPPED, save-unders NO
-  largest cursor:    1024x640
-  current input event mask:    0x580000
-    SubstructureNotifyMask   SubstructureRedirectMask PropertyChangeMask       
+  largest cursor:    1600x900
+  current input event mask:    0x5a0000
+    StructureNotifyMask      SubstructureNotifyMask   SubstructureRedirectMask 
+    PropertyChangeMask       
   number of visuals:    270
   default visual id:  0x24
   visual:
@emersion

This comment has been minimized.

Copy link
Member

emersion commented Jul 19, 2018

Just lost a few more hours trying to fix this.

Both Weston and wlc have a 24-bit color depth for the root window and the WM window. Setting a 32-bit color depth for the WM window doesn't change anything.

On Weston Firefox chooses a 24-bit color depth for its main window, but a 32-bit depth for its menu. On wlroots it chooses 24-bit for both.

@progandy

This comment has been minimized.

Copy link

progandy commented Jul 19, 2018

@ddevault

This comment has been minimized.

Copy link
Member

ddevault commented Jul 19, 2018

Doesn't appear to work for me.

@emersion

This comment has been minimized.

Copy link
Member

emersion commented Jul 19, 2018

Doesn't work for me.

But hey, wtf https://github.com/mozilla/gecko-dev/blob/fd5c37f1dd9a0d1e327a6c6b4d81ea92f52c4330/layout/xul/nsMenuPopupFrame.cpp#L311

EDIT: ah so that was your "Firefox does some strange things" x)

@c-edw

This comment has been minimized.

Copy link
Contributor

c-edw commented Nov 6, 2018

#2902 is fixed but I have noticed another minor bug with text dragging. There's a 'white flash' for a brief moment. I wouldn't say it's worth chasing after unless you already know the cause.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment