Support SHAPE extension

[totaam]

Issue migrated from trac ticket # 501

component: core | priority: minor | resolution: fixed

2014-01-24 13:28:56: norman created the issue

---

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

[totaam]

See:

• X Nonrectangular Window Shape Extension Library
• X Nonrectangular Window Shape Extension Protocol

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

[totaam]

2015-06-17 13:46:48: antoine uploaded file shape-v1.patch (7.6 KiB)

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

[totaam]

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.

[totaam]

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:
[[Image(XP-seamless-Linux.png)]]

[totaam]

2015-06-17 21:39:27: antoine uploaded file XP-seamless-Linux.png (99.0 KiB)

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

[totaam]

2015-06-18 16:59:12: antoine uploaded file xshape.c (3.3 KiB)

example xshape code

[totaam]

2015-06-18 16:59:30: antoine uploaded file cairo-xshape-example.c (3.4 KiB)

cairo xshape example

[totaam]

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

• [https://semicomplete.googlecode.com/svn-history/2741/codesamples/cairo-xshape-example.c]
• xshape example which seems to live here now: [https://github.com/grahamg/untitledwm/wiki/xshape-example]

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.

[totaam]

2015-06-18 18:01:37: antoine uploaded file shapedwindow.py (2.9 KiB)

python gtk example

[totaam]

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.

[totaam]

2015-06-22 18:37:45: maxmylyn commented

---

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!

[totaam]

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.

[totaam]

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