Fluxbox window borders disappear when running

[ghost]

Using compton -f -D8 -I0.05 -O0.05 &, the 1px wide borders around Fluxbox windows don't render, but Fluxbox behaves as though they are there with window snapping.

I can provide screenshot(s) if necessary.

[richardgv]

I'm afraid you would have to supply a screenshot, detailed steps to reproduce the issue, and your theme. I installed fluxbox-1.3.2, tried various things: starting compton in .xinitrc or when X is running; with your switches and without; 1px window border and 10px window border; build of the master branch or my richardgv-dev branch; resizing, moving, and minimizing windows, and I must admit I'm a bit out of luck, never being able to reproduce your bug.

Please also provide the version and compiling options of your Fluxbox (fluxbox --info) if convenient. Oh, and the version of your compton, of course.

I discovered another bug, though. Compton probably does not adjust window frame width when Fluxbox does it -- for example when switching theme on the fly. However this should only affect a user when using -e (frame_opacity) switch. I will look into this issue when I finish my work.

[ghost]

I typically start compton in ~/.xinitrc, though I've tried running it after X has started and get the same results.

Here's a screenshot: http://sporkbox.us/files/images/screens/comp/fluxbox-border-issue.png (warning, 1920x1080) The root terminal has been snapped to the bottom left corner, and yet there's a 1px wide transparent border when it should be black.

Output of fluxbox --info:

Fluxbox version: 1.3.2-gentoo
Compiled: Sep  9 2012 20:07:54
Compiler: GCC
Compiler version: 4.5.3

Defaults: 
    menu: /usr/share/fluxbox/menu
   style: /usr/share/fluxbox/styles/Emerge
    keys: /usr/share/fluxbox/keys
    init: /usr/share/fluxbox/init
     nls: /usr/share/fluxbox/nls

Compiled options (- => disabled): 
-BIDI
-DEBUG
EWMH
IMLIB2
NLS
REMEMBER
RENDER
SHAPE
-SLIT
TOOLBAR
XFT
-XINERAMA
XMB
XPM

I'm running compton 0.0.1.

.xinitrc:

export BROWSER="firefox"
export GTK_IM_MODULE=scim
export QT_IM_MODULE=scim
export XMODIFIERS=@im=scim

eval $(gpg-agent --enable-ssh-support --daemon) &
scim -d
xset r rate 200 30
xset m 4 5
/usr/local/bin/bamboo
xmodmap ~/.Xmodmap
compton -f -D8 -I0.05 -O0.05 &
conky &
urxvt &

exec fluxbox

Lastly, my Fluxbox theme: https://gist.github.com/3751607

What's strange is that it's omitting the borders when I first start Fluxbox, but if I kill and restart compton a few times, borders are correctly rendered again. This is very strange behavior...

[richardgv]

I could reproduce this problem. But what I found is, Fluxbox window frame of a window with 32-bit visual appears semi-transparent if xcompmgr/compton is running. It happens on the ARGB windows, so when you enable ARGB background in your terminal, its border becomes semi-transparent.

I made the border 10px wide to show the issue. The urxvt window started with ARGB background gets semi-transparent border.

Another one. I started urxvt with urxvt -depth 32, without actually making the background transparent, and the problem appears:

I don't think you would be able to make the Fluxbox border of an ARGB window solid by just restarting compton -- I don't see this, at least. If you could see it, just tell us the exact steps to make it happen.

Considering the following facts:

1. xcompmgr exhibits the same behavior;
2. I don't see other window managers have the same problem.
3. Someone once reported Fluxbox has issues handling ARGB32 visuals, although it has been marked as solved;
4. Compton does little special treatment for ARGB windows. Even if I let solid windows be rendered in the same way an ARGB window is, the problem does not appear on solid windows.

I'm more inclined to believe that this probably is more closely related to Fluxbox.

./src/FbWinFrame.cc in Fluxbox source code is responsible for the frames, looks like, but I didn't find why this problem would appear in the file.

Building Fluxbox from current git source does not seem to help.

By the way, I don't think compton has formal releases yet. (chjj looks unwilling.) There's no effective version number, and please always test with a build of the current master branch (or my richardgv-dev branch, if you want do a bit aggressively), or at least tell us the date of your source code or the last commit number.

[chjj]

Thank you for finding the fluxbox issue, richardgv. These patches might provide some insight on what's happening. After taking a quick peek at the fluxbox tree, it looks like both of these patches were applied and still exist.

Relevant links:

• http://git.fluxbox.org/fluxbox.git/tree/src
• http://git.fluxbox.org/fluxbox.git/tree/src/FbTk/FbWindow.cc
• http://git.fluxbox.org/fluxbox.git/tree/src/FbTk/FbWindow.hh
• http://git.fluxbox.org/fluxbox.git/tree/src/FbRootWindow.cc
• http://git.fluxbox.org/fluxbox.git/tree/src/FbRootWindow.hh
• http://git.fluxbox.org/fluxbox.git/tree/src/Window.cc
• http://git.fluxbox.org/fluxbox.git/tree/src/Window.hh

If the problem manifests in xcompmgr, I'm very surprised this is the first time it's been reported here. I wonder if an older commit of compton inadvertently fixed this problem, and then we happened to unknowingly cause it again.

Compton does little special treatment for ARGB windows. Even if I let solid windows be rendered in the same way an ARGB window is, the problem does not appear on solid windows.

It might be worth mentioning... the original xcompmgr did not allow clientside shadows on ARGB windows like urxvt (this is one of the reasons I originally created compton). I doubt this was a mistake on the devs' part, because it seemed somewhat explicit in the code. This may be for some reason only X11 gurus understand, but it seems like ARGB windows naturally have some kind of conflict with libxrender and XRenderComposite? I wouldn't blame this all on fluxbox. When I created compton, I simply removed the conditional that prevents shadows from being composited onto the buffer with the argb window.

By the way, I don't think compton has formal releases yet. (chjj looks unwilling.)

Several distros just pull from the master branch for their packages. I can do formal releases, but I don't know how easily they would catch on. I was thinking of tagging commits as versions and just having a staging/development branch, which would hold current development (your branch pretty much serves as this right now), and when we do a release, tag and push to master.

[richardgv]

If the problem manifests in xcompmgr, I'm very surprised this is the first time it's been reported here. I wonder if an older commit of compton inadvertently fixed this problem, and then we happened to unknowingly cause it again.

Considering it's a very small annoyance and ARGB windows are not commonly seen, I would presume it's not entirely unreasonable that it's the first time it's reported here. Look, xcompmgr has the issue, too, but has anyone reported it to xcompmgr devs?

..the original xcompmgr did not allow clientside shadows on ARGB windows like urxvt...

At least right now seemingly xcompmgr -c would painting shadows on ARGB windows... In some cases only. xcompmgr does not paint shadow on an ARGB window created before it starts running, but ARGB windows created when it's running get shadows. Well, I thought 10 years of development is enough to stop such apparent bugs from appearing in xcompmgr.

... but it seems like ARGB windows naturally have some kind of conflict with libxrender and XRenderComposite ...

Not entirely impossible. Yet I would imagine these X developers should have already resolved most issues after these years.

Several distros just pull from the master branch for their packages. I can do formal releases, but I don't know how easily they would catch on. I was thinking of tagging commits as versions and just having a staging/development branch, which would hold current development (your branch pretty much serves as this right now), and when we do a release, tag and push to master.

What I saw is the master branch of a project contains the code currently under development, in most cases, I would say. (Very experimental code and development on specific directions sometimes does not go into master branch, though.) They use tags to mark specific versions, and only create a stable maintenance branch if there's a big change in version number. (When 2.0 is pushed out, they would create a stable 1.x maintenance branch that usually only contains bug fixes.) It probably isn't an ordinary choice to use master as a stable branch. If distros pull from the master branch right now and count it as a cutting-edge version, turning master branch to a stable branch may immediately cause confusions.

So my suggestion is to use master for development code, and your commits go directly to it (unless you make a big change and want some time to test); my commits go into richardgv-dev and you periodically review and merge them to master (as my code is more error-prone than yours); when it's time for a release you just create a tag on the master branch. Not sure if GitHub will automatically create a tarball for you for a tag.

By the way, I don't think there's a point for these branches containing code already merged into master (better_debug, clear_shadow, new_refactor) to exist. Maybe you could just remove those branches?

[ghost]

@richardgv After playing around with it, it indeed seems to be only urxvt that's experiencing the border problem. As for the versioning, the ebuild for compton seems to be from 2012-03-30. I'm not entirely sure if that was simply the last time the ebuild was written and it fetches the current HEAD from master, or if it's a static release. The Gentoo dev hasufell maintains Gentoo's compton package and may have more information.

[richardgv]

@sporkbox:

Glad to meet another Gentoo user. x11-misc/compton-0_pre20120330 uses a snapshot of the master branch of compton from March, I suppose. Please use the x11-misc/compton-9999 ebuild in Portage tree.

If you wish to get a build of richardgv-dev branch, you could copy the ebuild to your local overlay and add EGIT_BRANCH="richardgv-dev", or just run this command (environment variables work for one time only, as you should know, unless you add that to package.env):

compton_LIVE_BRANCH="richardgv-dev" emerge -av '=compton-9999'

If you wish to build the code of a specific commit or have other requirements, Gentoo's git-2.eclass has more goodies.

[ghost]

@richardgv: I'm still new to Gentoo. Is there a guide out there for custom overlays? I managed to install an overlay to get Minecraft, but I'm clueless on creating my own. I believe I can force a package version, so compton-9999 would always be fetched or something.. but again, I'm new to Gentoo's methodology. I'll do some reading on it and try to get the compton-git version.

You tested the bug with the current HEAD and it's still there though, correct? I think this may be pointing to a bug in either Fluxbox or rxvt-unicode, since it seems to be the only application affected by it. Perhaps other 32-bit-capable terminals are also affected.

[richardgv]

@sporkbox:

I'm still new to Gentoo. Is there a guide out there for custom overlays? I managed to install an overlay to get Minecraft, but I'm clueless on creating my own. I believe I can force a package version, so compton-9999 would always be fetched or something.. but again, I'm new to Gentoo's methodology. I'll do some reading on it and try to get the compton-git version.

Oh, hmm, so I will make a detailed explaination here. if you wish to get the development code of compton, firstly you should add the 9999 version to package.keywords so Portage permits you to install it. Just make sure this line is in your /etc/portage/package.keywords:

=x11-misc/compton-9999 **

Now, if you wish to get the development code from the master branch, just execute:

emerge -av '=x11-misc/compton-9999'

As we often make new changes to the master branch, it makes sense to periodically fetch the changes and rebuild compton. Just re-execute the command above should be sufficient. If you are a portage-2.2-alpha user, this command rebuilds all 9999 packages:

emerge -av @live-rebuild

If you wish to fetch from richardgv-dev branch, which sometimes contains some newer code (which could be instable), run this command:

compton_LIVE_BRANCH="richardgv-dev" emerge -av '=compton-9999'

Beware that the environment variable affects this emerge session only, i.e. if you don't add it next time when you build compton, emerge will fetch from the master branch instead of richardgv-dev branch. You could make it persist by adding it to package.env or create a custom ebuild, but maybe you should just pull from the master branch right now.

gentoo-wiki.com has an article explaining how to create a custom overlay and add ebuilds to it, by the way.

You tested the bug with the current HEAD and it's still there though, correct? I think this may be pointing to a bug in either Fluxbox or rxvt-unicode, since it seems to be the only application affected by it. Perhaps other 32-bit-capable terminals are also affected.

Hmm, I don't think this could be a problem of rxvt-unicode, but... Let me find another ARGB app to test.

Update: gnome-terminal exhibits the issue, too.

[colons]

i'm a dwm, compton-0.1~beta2 and urxvt-v9.21 user on ubuntu, and i'm trying to get real transparency and my borders to match my status bar at the same time, but i can't because of what i believe to be this issue:

am i in the right place?

[undying]

Tried latest versions of compton and fluxbox (from master) and the this problem still appears. Is there any workaround?

[richardgv]

@colons:

I am unfortunately having problems comprehending your description. Did you mean the color of the borders of ARGB windows is different from the ones of 24-bit visual windows under dwm? That is probably a bug in dwm, see https://github.com/chjj/compton/issues/240#issuecomment-62245919 for a patch to fix it. (And indeed the fluxbox might be caused by similar reasons.)

[richardgv]

A temporary fix for fluxbox-1.3.7:

diff -ur fluxbox-1.3.7/src/FbTk/FbWindow.cc fluxbox-1.3.7-new/src/FbTk/FbWindow.cc
--- fluxbox-1.3.7/src/FbTk/FbWindow.cc  2015-02-08 18:44:45.357187009 +0800
+++ fluxbox-1.3.7-new/src/FbTk/FbWindow.cc  2015-09-06 16:32:32.500080578 +0800
@@ -251,7 +251,21 @@
 }

 void FbWindow::setBorderColor(const FbTk::Color &border_color) {
-    XSetWindowBorder(display(), m_window, border_color.pixel());
+   // richardgv: Ugly hack to decide the pixel value based on the colormap of
+   // the window {{{
+   unsigned long pixel = border_color.pixel();
+   XWindowAttributes attr;
+   if (XGetWindowAttributes(display(), m_window, &attr)
+           && attr.colormap != DefaultColormap(display(), m_screen_num)) {
+       XColor color;
+       color.red = border_color.red() * 0x101;
+       color.green = border_color.green() * 0x101;
+       color.blue = border_color.blue() * 0x101;
+       if (XAllocColor(display(), attr.colormap, &color))
+           pixel = color.pixel;
+   }
+   // }}}
+    XSetWindowBorder(display(), m_window, pixel);
     m_border_color = border_color.pixel();
 }

The issue is Fluxbox, like dwm, does not care about the colormap of the window when it sets the border color, and always assumes it is using the default colormap.

It is far from optimal to call XWindowAttributes() each time FbWindow::setBorderColor() is called. But Fluxbox FbWindow and Color class does not record information about colormaps, making it tricky to produce a nice fix without touching too many places.

[undying]

Im applied the patch and found that borders on terminal screens are not disappearing anymore. But when Im using arandr for switching to the multihead mode (Xinerama), borders are disappearing for new terminal windows. I have used Rox Terminal and Sakura terminal. The exception is Eterm, his border is never disappeared.

[colons]

thanks, @richardgv; unfortunately, i'm compiling dwm directly from their git repository and don't understand what's going on well enough to port that patch to a later version. i can't roll back to 6.0 without big changes to my config.h, too

you seem well equipped, though; is there any chance you could try to get a fix included in suckless' development version?

[ceving]

I have a similar problem here. When I bring a window to the foreground, the border of the overlapped area is missing. But I can not give a screen shot. When I try to capture the error with xwd or gimp the result is correct. It seems to me that taking a screen shot triggers some kind of exposure, which corrects the error.

[g3ngr33n]

Same here with 1.3.7-r3 on Gentoo, I can see the border on the start of urxvt for less than 1 second before it disappear, I tried taking a screenshot after reading the comment of ceving with xwd and scrot , the color of the border does not show.

Edit : I found a "clue" of the problem, It work without passing the option -tr of rxvt-unicode (pseudo transparency of the background)