Date: Fri, 27 Mar 2015 13:57:32 -0400 From: Ken Moore <ken@pcbsd.org> To: freebsd-x11@freebsd.org Subject: 10.x -> 11 changes in compositing behavior Message-ID: <55159A0C.5000300@pcbsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55159A0C.5000300>