Xpra trac archive

Xpra: Ticket #2495: macos shows a shadow on transparent windows

Tested using deepin-music (testing for #2493).

For whatever reason, this app draws a much bigger transparent window around the window contents. (see #2493) On macos, we can see a shadow around this transparent window: shadow around the transparent window


Tue, 26 Nov 2019 15:54:31 GMT - Antoine Martin: attachment set

shadow around the transparent window

Tue, 26 Nov 2019 15:55:44 GMT - Antoine Martin: status, description changed

Sat, 29 Feb 2020 08:48:53 GMT - Antoine Martin: attachment set

shadow around a popup menu

Sat, 29 Feb 2020 09:14:52 GMT - Antoine Martin: attachment set

xpra screenshot

Sat, 29 Feb 2020 09:22:59 GMT - Antoine Martin:

Still using deepin-music, the shadow around the main window is gone, but there is a shadow around the popup menu: shadow around a popup menu For this window: 

process_new_common: [19, 833, 307, 163, 181, \
    {b'xid': b'0x60006b', b'has-alpha': True, b'client-machine': b'desktop-eth0', b'pid': 493505, \
     b'title': b'Deepin Music', b'class-instance': (b'deepin-music', b'deepin-music'), b'transient-for': 2, \
     b'group-leader-xid': 6291464, b'window-type': (b'_KDEOVERRIDE', b'NORMAL'), b'override-redirect': True}], ... , OR=True
GLClientWindow(19 : GLDrawingArea(19, (163, 181), None)).window_state_updated(GLClientWindow(19 : GLDrawingArea(19, (163, 181), None)), <Gdk.EventWindowState object at 0x10e77a5e0 (void at 0x7fe828171810)>) changed_mask=<flags GDK_WINDOW_STATE_WITHDRAWN | GDK_WINDOW_STATE_FOCUSED of type Gdk.WindowState>, new_window_state=<flags GDK_WINDOW_STATE_FOCUSED of type Gdk.WindowState>
_focused=True (was False)
window_state_updated(..) state updates: {'focused': True}, actual updates: {'focused': True}, server updates: {'focused': True}

Interestingly, the xpra screenshot commands shows the shadow around the main window does exist, but it is fully transparent: xpra screenshot

The popup is an OR window, and it does use 32-bit colour, with transparency: 

windows.19.XShm=True
windows.19.above=False
windows.19.allowed-actions=('_NET_WM_ACTION_CLOSE', '_NET_WM_ACTION_MOVE', '_NET_WM_ACTION_RESIZE', '_NET_WM_ACTION_FULLSCREEN', '_NET_WM_ACTION_MINIMIZE', '_NET_WM_ACTION_SHADE', '_NET_WM_ACTION_STICK', '_NET_WM_ACTION_MAXIMIZE_HORZ', '_NET_WM_ACTION_MAXIMIZE_VERT', '_NET_WM_ACTION_CHANGE_DESKTOP', '_NET_WM_ACTION_ABOVE', '_NET_WM_ACTION_BELOW')
windows.19.below=False
windows.19.bypass-compositor=0
windows.19.class-instance=('deepin-music', 'deepin-music')
windows.19.client-machine=desktop-eth0
windows.19.command=
windows.19.content-type=
windows.19.depth=32
windows.19.focused=False
windows.19.fullscreen=False
windows.19.geometry=(833, 307, 163, 181)
windows.19.grabbed=True
windows.19.has-alpha=True
windows.19.maximized=False
windows.19.opacity=-1
windows.19.override-redirect=True
windows.19.pid=493505
windows.19.shaded=False
windows.19.shown=True
windows.19.size=(163, 181)
windows.19.skip-pager=False
windows.19.skip-taskbar=False
windows.19.state=('_NET_WM_STATE_FOCUSED',)
windows.19.sticky=False
windows.19.title=Deepin Music
windows.19.transient-for=2
windows.19.tray=False
windows.19.window-type=('_KDEOVERRIDE', 'NORMAL')
windows.19.workspace=65535
windows.19.xid=0x60006b

The screen update comes down as webp, with transparency: 

process_draw:    2468    bytes for window  22, sequence        1,  163x181  at    0,0    using   webp encoding with options={b'rgb_format': b'BGRA', b'quality': 100}

Sat, 29 Feb 2020 12:25:21 GMT - Antoine Martin: priority changed

The popup menu issue is reproducible on Linux fairly reliably, where we get 2 screen updates, the second one arrives ~300ms later and "fixes" the rendering using transparency (BGRA): 

process_draw:       1   arrays for window  38, sequence        1,  163x181  at    0,0    using   mmap encoding with options={b'rgb_format': b'RGB'}
process_draw:       1   arrays for window  38, sequence        2,  163x181  at    0,0    using   mmap encoding with options={b'rgb_format': b'BGRA', b'window-size': (163, 181)}

With full debug: 

Discovered new override-redirect window: 0x600048 X11 geometry=(813, 201, 181, 202, 0, 32)
updateprop(depth, 32) previous value=None
damage handle(0x600048)=0x400030
update_encoding_options(False) wid=7, want_alpha=False, speed=80, quality=100, bandwidth-limit=0, lossless threshold: 56 / 5, rgb auto threshold=9216 (min=2048, max=32768), get_best_encoding=<bound method WindowSource.encoding_is_mmap of WindowVideoSource(7 : (181, 202))>
initial encoding for 7: auto
send_delayed_regions: using full window update 181x202 as  mmap: merged region covers almost the whole window, from <bound method WindowSource.encoding_is_mmap of WindowVideoSource(7 : (181, 202))>
<bound method CoreX11WindowModel.get_image of OverrideRedirectWindowModel(0x600048)>(0, 0, 181, 202)=XShmImageWrapper(BGRA: 0, 0, 181, 202)
compress:   0.4ms for  181x202  pixels at    0,0    for wid=7     using      mmap with ratio   0.0%  (  142KB to     0KB), sequence     1, client_options={'rgb_format': 'RGB'}
..
update_encoding_options(False) wid=7, want_alpha=True, speed=80, quality=100, bandwidth-limit=0, lossless threshold: 56 / 5, rgb auto threshold=27648 (min=2048, max=32768), get_best_encoding=<bound method WindowSource.encoding_is_mmap of WindowVideoSource(7 : (181, 202))>
<bound method CoreX11WindowModel.get_image of OverrideRedirectWindowModel(0x600048)>(0, 0, 181, 202)=XShmImageWrapper(BGRA: 0, 0, 181, 202)
compress:   0.2ms for  181x202  pixels at    0,0    for wid=7     using      mmap with ratio   0.0%  (  142KB to     0KB), sequence     2, client_options={'rgb_format': 'BGRA'}

So the problem comes from the fact that we end up with want_alpha=False initially, and we convert the image to RGB.

Sun, 01 Mar 2020 08:06:40 GMT - Antoine Martin: status changed; resolution set

Two problems:

Both are fixed in r25444 (backport in r25445)

These two bugs were not actually specific to macos.

Sat, 23 Jan 2021 05:52:51 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2495