Date: Fri, 27 Mar 2015 15:13:16 -0400 From: Ken Moore <ken@pcbsd.org> To: freebsd-x11@freebsd.org Subject: Re: 10.x -> 11 changes in compositing behavior Message-ID: <5515ABCC.1070203@pcbsd.org> In-Reply-To: <55159A0C.5000300@pcbsd.org> References: <55159A0C.5000300@pcbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/27/2015 13:57, Ken Moore wrote: > 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) > So I found a work-around, not sure where the problem was exactly, but using the Qt method for grabbing an image from a window (QScreen->grabWindow()) seems to work fine on FreeBSD 11 (even with the manual composite redirection set) whereas directly fetching the image through XCB/XLib was not. Perhaps it has better fallback/alternate routines? Sorry for the noise! -- ~~ Ken Moore ~~ PC-BSD/iXsystems
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5515ABCC.1070203>