Xpra: Ticket #501: Support SHAPE extension

xeyes and xclock use this extension to have non-rectangular windows, low priority feature request to support it.

Fri, 24 Jan 2014 13:33:35 GMT - Antoine Martin: owner, status, description changed; milestone set

owner changed from Antoine Martin to Antoine Martin
status changed from new to assigned
description modified (diff)
milestone set to 1.0

See:

Looks like we should select for shape events with XShapeSelectInput and call XShapeGetRectangles to get the list of rectangles for a window, then we can pass that to the client...

Then the client can use gdk.Window.shape_combine_mask Here is an example: shapedwindow.py

Wed, 17 Jun 2015 12:46:47 GMT - Antoine Martin: attachment set

attachment set to shape-v1.patch

work in progress patch: send shape as metadata to X11 clients

Wed, 17 Jun 2015 12:49:14 GMT - Antoine Martin:

The patch above does most of what we need, except:

always reading the initial value of shape
structuring the data for the different kinds of shapes (bounding and clip)
actually using it client side: do we want to call the X11 layer directly? (easier since we don't cook the data as per gtk's mask interface - but maybe this works on win32 and osx via gtk?)

We probably want this in a reasonable shape (pun intended) before closing #885.

Wed, 17 Jun 2015 20:32:04 GMT - Antoine Martin:

Mostly done in r9657, this will do for now. xeyes works!

Remaining items (which may well get re-scheduled):

we're using the metadata packet, which is fine unless an application creates a storm of updates (why would they?) - we could convert the rectangles to a 1-bit image and compress it, sending it from the encode thread to prevent this bottleneck (meh). we may need to bump the max packet size limit, or whitelist the metadata packet (a fullscreen xeyes is enough to trigger the packet size warning), or even use a dedicated packet? (also meh)
not sure where we're supposed to get the offset passed in to XShapeCombineRectangles, maybe from the "extents" values? (until an app uses it, I'm not sure)
osx support: no idea (see Setting a Window’s Appearance?)
win32: UpdateLayeredWindow requires a layered window, and A layered window is created by specifying WS_EX_LAYERED when creating the window with the CreateWindowEx? function. - so I'm not sure this can be made to work with GTK...

And this shows off what is now possible with virtualbox seamless and remoted via Xpra:

Wed, 17 Jun 2015 20:39:27 GMT - Antoine Martin: attachment set

attachment set to XP-seamless-Linux.png

shows off VirtualBox?'s seamless mode running within Xpra: IE8 and control panel directly on the Linux desktop

Thu, 18 Jun 2015 15:59:11 GMT - Antoine Martin: attachment set

attachment set to xshape.c

example xshape code

Thu, 18 Jun 2015 15:59:29 GMT - Antoine Martin: attachment set

attachment set to cairo-xshape-example.c

cairo xshape example

Thu, 18 Jun 2015 16:52:24 GMT - Antoine Martin:

Found some examples to use for testing (beyond xeyes and virtualbox):

The source is now attached to this ticket in case googlecode loses yet more code.

The first one shows that the implementation is missing something: the window ends up not being transparent... The second one works fine.

I have moved the osx and win32 items to #893.

Thu, 18 Jun 2015 17:01:37 GMT - Antoine Martin: attachment set

attachment set to shapedwindow.py

python gtk example

Thu, 18 Jun 2015 17:58:08 GMT - Antoine Martin: owner, status changed

owner changed from Antoine Martin to alas
status changed from assigned to new

Well, well. Turns out this is a bit of a monster of a bug, and not in the xshape code at all: r9671 fixes xshape for OR windows in trunk, as well as a long list of other properties we were failing to propagate for OR windows: "title", "size-hints", "fullscreen", "fullscreen-monitors", "bypass-compositor", "maximized", "opacity", "workspace", "strut", "shape".

This should be backported to all supported branches, but I think I'll just wait for the next point release to make sure this does not have undesirable side effects.

Apart from that, this is ready for testing, just connect with a Linux client and fire up one of the test applications:

xeyes
virtualbox in seamless mode
python shapedwindow.py

compile then run the C examples, ie:

gcc $(pkg-config xext x11 cairo-xlib-xrender --cflags --libs) cairo-xshape-example.c -o cairo-xshape-example
./cairo-xshape-example

gcc $(pkg-config xext x11 --cflags --libs) xshape.c -o xshape
./xshape

@afarr: mostly a FYI, feel free to close as an acknowledgement.

Mon, 22 Jun 2015 17:37:45 GMT - J. Max Mena: status changed; resolution set

status changed from new to closed
resolution set to fixed

Started a r9688 Fedora 21 Trunk Server:

shapedwindow.py works as expected when connecting from Fedora 20 Trunk r9688

Windows has a nice border

Consulted with Alex, and this has been acknowledged. Closing!

Sat, 24 Oct 2015 04:58:24 GMT - Antoine Martin: milestone changed

milestone changed from 1.0 to 0.16

(fix milestone)

Sat, 11 Jun 2016 11:11:11 GMT - Antoine Martin:

Problem is that the scaling code added in r10652 is too slow, so r12781 defaults to the lazy direct scaling of rectangles - will backport. This fixes latest versions of google-chrome which seem to reset the xshape values far too often, causing multi-second stalls.

Mon, 31 Oct 2016 11:29:16 GMT - Antoine Martin:

r14363 makes it possible to disable the xshape code with the XPRA_SHAPE=0 env var.

Sat, 23 Jan 2021 04:57:31 GMT - migration script:

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