XShape'ed window are not correctly handled if they change their shape, especially if the new shape is "smaller" than the previous. Windows changing shape mask but not geometry are affected, windows changing geometry and mask are also affected. To reproduce, just launch 'xeyes' and resize its window. As you shrink the window, it will leave some part on the screen. Move windows around to refresh the screen. Tested under various window manager (kwin and metacity). See this video xcompmgr-1.1.4.ogv on http://people.mandriva.com/~ydroneaud/compmgr/ Remark: Metacity 2.24.0 show quite the same behavior. Kwin 3.0 and Compiz 0.7.8 have a correct behavior.
Created attachment 24240 [details] [review] Try to fix xshape'ed window Here is a patch I wrote with help from fredrikh on #xorg-devel. It's not a definitive answer to this problem because: - calling paint_all() for each ShapeNotify event is painfully slow - window using ARGB visual and XShape have to be handled specifically In fact, my test program sometime shows a black background after removing the shape, the black background disappear after some little time, probably the time needed for the composite manager to process all ShapeNotify events so this could be related to the slowness reported above
Created attachment 24271 [details] [review] Improved fix: repaint only some part of screen This new patch improve the call to paint_all() to redraw only affected region of the screen (the old region union the new region covered by the shape). It's really faster, and now I no more see black background around my test window. This patch is still not perfect since it's still not have support for windows using ARGB visual and a ShapeBounding (rendering will be done using PictOpSrc instead of PictOpOver).
Created attachment 34101 [details] [review] Patch to handle shaped argb and transparent windows This is a patch which handles the shape extension also for argb and transparent windows. This patch was applied against a fresh xcompmgr-1.1.5 without the patches from Yann Droneaud.
(In reply to comment #3) > Created an attachment (id=34101) [details] > Patch to handle shaped argb and transparent windows > > This is a patch which handles the shape extension also for argb and > transparent windows. This patch was applied against a fresh xcompmgr-1.1.5 > without the patches from Yann Droneaud. > I've tried xcompmgr + this patch with my test program and did not found any improvement. Same things with xeyes. Did you have a test case to demonstrate your patch ?
Created attachment 34102 [details] test program for "Patch to handle shaped argb and transparent windows" My patch is only thought as an extension to your patch (since my patch does not watch for shape changes). But this patch handles argb windows, which have a shape set. You can try the attached program (needed python modules: pygtk and notify-python). It creates a GtkStatusIcon and calls a notification-message which is attached to the GtkStatusIcon (an arrow should display onto the status icon). Without my patch, the area which should be cut out by the shape extension, contains random colors. With my patch, the shape is respected. BTW: I cannot see xeyes failing, with a fresh xcompmgr-1.1.5?
Created attachment 34104 [details] [review] Merged patch 24271 & 34101 Merged both patches to be able to draw shaped argb windows, but also listening on a shape change. This probably shows what my patch exactly does, since now we do not need to check in paint_all(...) whether a window is shaped or not. We can just draw it, as it was before...
(In reply to comment #6) > Created an attachment (id=34104) [details] > Merged patch 24271 & 34101 > > Merged both patches to be able to draw shaped argb windows, but also listening > on a shape change. > This probably shows what my patch exactly does, since now we do not need to > check in paint_all(...) whether a window is shaped or not. We can just draw it, > as it was before... > I've tested it, and I have to congratulate you, it seems you have fixed this bug. Add the missing dependencies to Xext and send the patch to the X.Org Devel List <xorg-devel@lists.freedesktop.org>, with me as Cc:.
What is blocking the inclusion of this? Does xcompmgr just not have a single assigned maintainer, or is it really unmaintained and discontinued? This is probably the wrong place to ask, but I hope at least someone who knows the answer is Cc'd. (I'm asking mainly because on Sandy Bridge, with rc6 enabled -- which saves more than 4 watts and does not cause any hangs -- there's a quite annoying tearing when scrolling in vim in urxvt, and compositing seems to be a handy workaround. Perhaps I should file a bugreport, but I don't know whether this is kernel issue or userspace issue. And, anyway, xcompmgr is the only way to get ARGB visuals with xmonad and other lightweight window managers, so it would be really nice if it worked and was at least partially maintained.)
It's genuinely unmaintained, yeah. Patches are welcome, but no-one's working on it really.
No response. Assuming implied consent and creating a git commit as appropriate. commit 747977fbc42c6c9b4bb2a77d596f5d1e434d83c4 Author: Andreas <finkandreas@web.de> Date: Sun Sep 25 00:18:17 2011 -0700 Handle XShape window which shape change https://bugs.freedesktop.org/show_bug.cgi?id=20839 Tested-by: Yann Droneaud <yann@droneaud.fr> Signed-off-by: Andreas <finkandreas@web.de> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com> Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
xcompmgr 1.1.6 has been released with this fix in: http://lists.x.org/archives/xorg-announce/2012-February/001824.html
> --- Comment #11 from Alan Coopersmith <alan.coopersmith@oracle.com> 2012-02-14 19:30:16 PST --- > xcompmgr 1.1.6 has been released with this fix in: > http://lists.x.org/archives/xorg-announce/2012-February/001824.html > And there's a regression reported in #46285
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.