From owner-freebsd-x11@FreeBSD.ORG Fri Mar 27 19:13:34 2015 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C327DA25 for ; Fri, 27 Mar 2015 19:13:34 +0000 (UTC) Received: from barracuda.ixsystems.com (mail.ixsystems.com [69.198.165.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99E55807 for ; Fri, 27 Mar 2015 19:13:34 +0000 (UTC) X-ASG-Debug-ID: 1427483596-08ca041af101cb0002-0Qlll1 Received: from [192.168.1.130] (75-130-42-189.dhcp.buvl.tn.charter.com [75.130.42.189]) by barracuda.ixsystems.com with ESMTP id CVePF6sZKWvMtQkr (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 27 Mar 2015 12:13:18 -0700 (PDT) X-Barracuda-Envelope-From: ken@pcbsd.org X-Barracuda-AUTH-User: ken@pcbsd.org X-Barracuda-Apparent-Source-IP: 75.130.42.189 Message-ID: <5515ABCC.1070203@pcbsd.org> Date: Fri, 27 Mar 2015 15:13:16 -0400 From: Ken Moore User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-x11@freebsd.org Subject: Re: 10.x -> 11 changes in compositing behavior References: <55159A0C.5000300@pcbsd.org> X-ASG-Orig-Subj: Re: 10.x -> 11 changes in compositing behavior In-Reply-To: <55159A0C.5000300@pcbsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 75-130-42-189.dhcp.buvl.tn.charter.com[75.130.42.189] X-Barracuda-Start-Time: 1427483597 X-Barracuda-Encrypted: ECDHE-RSA-AES128-GCM-SHA256 X-Barracuda-URL: https://10.2.0.41:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=8.0 tests=BSF_SC1_TG070 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.17238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_SC1_TG070 Custom Rule TG070 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 19:13:34 -0000 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