xpra icon
Bug tracker and wiki

Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#279 closed enhancement (fixed)

32-bit visuals and transparent windows

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: minor Milestone: 0.10
Component: core Version: trunk
Keywords: Cc: onlyjob@…

Description (last modified by Antoine Martin)

Needed for things like #77 (see there for backing patch)

We need to:

  • add client caps (ie: "transparency"?)
  • detect when the window uses 32-bit visuals
  • make sure we use a 32-bit corral window (if client supports it and window uses 32-bit visuals)
  • pass the window depth to clients that support it
  • client windows should be created as 32-bit rgba windows if needed
  • return 32-bit pixel data as needed from get_rgb_rawdata, and the depth used so callers know about it
  • switch to encoders that support transparency (as some won't support it)
  • store transparency with the encoding (png should handle it ok, we should add a rgb32 mode, x264?, vpx?)

Extra difficulty:

  • pixbuf.get_from_drawable does not seem to handle things properly.. maybe we can use gdk_pixbuf_get_from_image instead?
  • security: we don't want to have a remote transparent window capable of stealing all input

Attachments (2)

transparency.patch (7.7 KB) - added by Antoine Martin 7 years ago.
adds basics for supporting transparency
dummy-32bits.patch (1.2 KB) - added by Antoine Martin 7 years ago.
naive hack to try to get 32-bit modes with dummy driver (not working)

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by Antoine Martin

Description: modified (diff)
Status: newassigned

Changed 7 years ago by Antoine Martin

Attachment: transparency.patch added

adds basics for supporting transparency

comment:2 Changed 7 years ago by Antoine Martin

Description: modified (diff)

comment:3 Changed 7 years ago by onlyjob

Cc: onlyjob@… added

comment:4 Changed 7 years ago by Antoine Martin

The biggest stumbling block is going to be the X11 server once again.

Neither Xvfb nor the dummy driver support 32-bit visuals, for whatever reason.
See this ticket for Xvfb.

I've tried to patch dummy to allow it but only got as far as this:

[128046.305] (II) DUMMY: Driver for Dummy chipsets: dummy
[128046.305] (WW) Falling back to old probe method for dummy
[128046.305] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[128046.305] (II) DUMMY(0): Chipset is a DUMMY
[128046.305] (II) DUMMY(0): Creating default Display subsection in Screen section
	"dummy_screen" for depth/fbbpp 32/32
[128046.305] (**) DUMMY(0): Depth 32, (--) framebuffer bpp 32
[128046.305] (EE) DUMMY(0): Weight given (000) is inconsistent with the depth (32)

Patch attached. Note: module loading is complicated and I hacked the ABI number rather than trying to figure out why the srpm did not install out of the box.

Last edited 7 years ago by Antoine Martin (previous) (diff)

Changed 7 years ago by Antoine Martin

Attachment: dummy-32bits.patch added

naive hack to try to get 32-bit modes with dummy driver (not working)

comment:5 Changed 7 years ago by Antoine Martin

Ignore comment:4, no changes to the X11 server were needed.
What we want are 32-bit visuals, you can get that from a 24-bit dummy server just fine.

r3368 now handles transparency (big changeset - lost of details in commit message)

Remaining work items:

  • verify pixel parsing on a big-endian server (and client?)
  • verify transparency handling (X11 transparency is pre-multiplied?)
  • test transparent system tray forwarding
  • servers without PIL should fallback to gtk pixbuf code
  • make it work with webp which is better (smaller/faster) than png and does transparency
  • change encoding availability detection: can vary depending on client or server, client type, window backing type, etc..
  • choose appropriate client window class based on alpha (no GL for now..)
  • handle alpha channel with GL client window

comment:6 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

Pretty much all done, see:

  • #280 systray
  • r3368 gtk2 pixmap backing code (+fixes in r3373 + r3457)
  • r3514 (webp)
  • r3371 (stub for GL: transparency not handled yet)
  • r3772 + r3771 don't bother sending transparency if client cannot handle it

That will do for now, win32 may get transparency if/when we move to gtk3/qt4 (#90).

Last edited 6 years ago by Antoine Martin (previous) (diff)

comment:7 Changed 6 years ago by Antoine Martin

Note: X11 pixel data is in pre-multiplied format, so we needed r4152 to display it properly with GTK (#416 to improve on that). I don't think it really matters to the encoders (only png and webp at present) if it's pre-multiplied or not.

comment:8 Changed 6 years ago by onlyjob

Since lack of transparency support should not be a problem any more why black rectangle still an issue with Firefox and expanding tree-style-tab?
Antoine, remember in https://www.xpra.org/trac/ticket/252#comment:24 you confirmed that you are able to reproduce the problem.
It never improved and as before the issue is only reproducible in active window... Any ideas why it still happening? Thanks.

comment:9 Changed 6 years ago by Norman Rasmussen

Should xeyes's transparently work correctly with this? Is there an example that does?

comment:10 Changed 6 years ago by Norman Rasmussen

xeyes uses the SHAPE extension, not transparency, so it's probably not expected to work :-)

comment:11 Changed 6 years ago by Antoine Martin

Milestone: 1.00.10

(set correct milestone work was completed in)

Note: See TracTickets for help on using tickets.