10.x -> 11 changes in compositing behavior
Ken Moore
ken at pcbsd.org
Fri Mar 27 17:57:50 UTC 2015
Greetings!
I am noticing a strange inconsistency between the behavior of windows
that have manual compositing redirect enabled between FreeBSD 10 and 11
systems. Basically, FreeBSD 10 is properly saving the window image on
the X11 server for use later without any issues, but on FreeBSD 11 all
that is getting saved is a transparent/blank image. The image *is* there
(kind of), since I can probe it and see the sizing and other properties,
but the image itself is blank.
Is there anything that has changed on FreeBSD 11 with regards to
when/how images are saved to the server?
I have posted my general procedure below, would you recommend something
different?
Thanks!
---- Additional Details ----
I am actually running into this with the Lumina Desktop system tray
functionality, so let me give you a quick overview of how that is
arranged, later on I will list a quick "pseudo-code" for you to
reproduce this.
Note: This is the general "embedding" procedure for a system tray icon
1) Reparent the tray window into the container window.
2) Set the "manual" compositing redirect on the tray window (having it
save it's image to the X11 server/stack, but not paint the image on the
window - resulting in a transparent overlay)
3) Have the container grab the tray window image from the stack, and
overlay/paint that image onto of itself (fixing issues with transparency
on systems not using a compositing window manager)
This results in the image actually being painted on the container, while
the tray window is a transparent "layer" above the container to directly
receive all the input/interaction events. This results in it responding
quickly and without a lot of overhead/redirection of all the various
kinds of input events.
If I simply comment out the manual compositing redirect (or set it to
automatic), the tray icon/image shows up just find but has a black
background where the image is transparent (it is not showing the
parent/container image underneath), so I have narrowed it down to that
one setting which is causing the problem but am kind of at a loss as to
how to fix/bypass it.
-------- Relevant Information ------
First off, the versions of xorg that I am comparing are identical
between the two systems:
xorg 7.7_1
xorg-apps 7.7_2
xorg-docs 1.7,1
xorg-drivers 7.7_2
xorg_server 1.14.7_2,1
My two systems:
1 - bare-metal) FreeBSD 10.1-RELEASE-p17 (Actually PC-BSD 10.1.1, up to
date with latest from freebsd-update and packages)
2 - VirtualBox VM) FreeBSD 11.0-CURRENTMAR2015 (PC-BSD March image for
FreeBSD 11, created Mar 1, ~2PM EST)
(although identical behavior has been found on the February image for
FreeBSD-Current as well, installed on either bare-metal or in a VM)
----- Steps to Reproduce -----
I am going to list both XCB and XLib commands that were used to
replicate this behaviour below. The XCB/XLib usage was consistant and
they were not "mixed" within an application.
-- General idea/usage for replicating the effect --
1) Set manual compositing redirect on a window to have it save it's
image on the stack but without painting it on the window itself.
xcb_composite_redirect_window(connection, window,
XCB_COMPOSITE_REDIRECT_MANUAL);
XCompositeRedirectWindow(display, window, CompositeRedirectManual);
2) Grab the image for the window from the stack at some later time
xcb_image_get()
XGetImage()
3) Paint the image so it can be viewed (I do it on a separate window)
--
~~ Ken Moore ~~
PC-BSD/iXsystems
More information about the freebsd-x11
mailing list