Garbled background with transparent windows in vertical split containers

[i3bot]

[Originally reported by kemurphy@…]
(With any transparent window (I've tested with urxvt and many vte-based terminals), I get garbled backgrounds in some of them when they are in a vertical split container while running any compositing manager like xcompmgr or cairo-compmgr. What's more curious is that the garbled background goes away if the window is moved to another workspace or if its container becomes anything that's not a vertical split, but if it goes back into a vertical split on it's original workspace, the garbled background comes back.

Steps to reproduce:

Start i3
Start xcompmgr
Switch to a clean workspace
Set its orientation to vertical and its layout to default
Launch two terminals with transparent backgrounds (I recommend sakura); the first one should get a garbled background.

With more than two windows, every window besides the most recently created window gets a garbled background. If the most recently created window itself is turned into a split container, the second most recently created window's background gets cured (and this effect cascades up for each window you turn into a split container).

I've examined my own log files and nothing seems to indicate anything is going wrong, and this issue was reproduced by another person in the irc channel as well.

[stapelberg]

Transparency is not supported or endorsed by i3. One could say it's tolerated. Therefore closing wontfix. If you care about it, send a patch.

[i3bot]

[Original comment by kemurphy]

Okay, that's fine, I can understand that. But i3 is the only window manager that exhibits this behavior, which makes me think there's something not right going on with the usage of xcb somewhere (in other words, it might be a correctness bug that doesn't just affect transparency). If you don't want to fix it, that's totally cool, but would you mind taking a glance through the source to tell me where to look to do it myself? It just seems like I'm not familiar enough with the workings of X11/xcb/i3 to track it down myself (and I had spent a lot of time looking before I filed this report).

[stapelberg]

Replying to comment 2 by kemurphy:

Okay, that's fine, I can understand that. But i3 is the only window manager that exhibits this behavior, which makes me think there's something not right going on with the usage of xcb somewhere (in other words, it might be a correctness bug that doesn't just affect transparency).
Unlikely. As far as I remember it’s just how we render things (overlaying stuff over other bits).

If you don't want to fix it, that's totally cool, but would you mind taking a glance through the source to tell me where to look to do it myself? It just seems like I'm not familiar enough with the workings of X11/xcb/i3 to track it down myself (and I had spent a lot of time looking before I filed this report).
Start by reading the hacking-howto, then have a close look at how we render (src/render.c). You might want to enable show_debug_borders at the top of that file. And/or change some of the rendering code and see what happens. Also have a look at src/x.c, especially x_draw_decoration which should be somewhat understandable.

In case you have detail questions, feel free to ask them on IRC and stick around.

[i3bot]

[Original comment by kemurphy]

Okay, I have a patch written. Is there any reason you didn't opt to just always use a 32 bit visual if it's available, and fall back to the X11 default if it's not (or throws an error)? This patch involves reverting 9d68d78 "Use 32bit visual only when needed." That commit failed to realize that "needed" included the extra windows that i3 creates for title bars. My patch also fixes windows not being transparent and not having borders after an i3 restart, and I think it also really simplifies src/x.c (drawing to the windows now only happens once, in a much saner manner than before).

[stapelberg]

We cannot revert this commit because using 32-bit visuals when not necessary slows down drawing on my Thinkpad X200 considerably.

Can you post a different patch which doesn’t revert the commit please?

[i3bot]

[Original comment by kemurphy]

Before I do that, can you at least try running with this patch on your machine to see if the slowdown is still there? Remember, I streamlined the drawing process in x.c; things that were getting drawn 3 or 4 times to a pixmap and 2 or 3 more to the window are now only drawn once; it should make a noticeable difference for you if enabling 32bit visuals slows you down that much.

[i3bot]

[Original comment by kemurphy]

Here's an updated patch that takes a config option or a command line switch to enable the alpha channel.

[i3bot]

[Original comment by kemurphy]

updated for better xcb usage

[stapelberg]

Thanks for updating the patch. Here are my comments:

1. Please split this up into multiple files. One of them should simply revert the commit, the other one should contain your changes. Currently, this is hard to review at all.
2. You do several changes to x.c without explaining any of them. These questions immediately pop up for example: Why did you kill our rendering cache? Why did you move the pixmap creation code?
3. You also changed lines for formatting only:

uint32_t values[] = { 0 }; 
xcb_create_gc(conn, con->pm_gc, con->pixmap, XCB_GC_GRAPHICS_EXPOSURES, values); 

to

xcb_create_gc(conn, con->pm_gc, con->pixmap, XCB_GC_GRAPHICS_EXPOSURES, (uint32_t[]) { 0 }); 

Please don’t do that as it distracts from what your patch actually does.

Can you please update your patch in such a way that:

1. You don’t do as many modifications as you do currently
2. it is clear what you do in each step?

Ideally, this leads to multiple patches with understandable and clear commit messages stating what you changed, what the precise problem was and how it was fixed.

[i3bot]

[Original comment by kemurphy]

Sure, though things just got pretty busy for me at my job, so it may be a week or two before I get to splitting it up.

The changes in x.c to remove the rendering cache were necessary because either it was bad/wrong, or it was good/correct and just did not play nicely with transparent windows. (My intuition is it was a combination of both; some of the caching cases made sense and others looked rather dubious to me. In fact, this is the kind of correctness issue I was suspicious of when I first reported the bug.) After globally enabling 32-bit visuals, I noticed that windows in vertical splits no longer had the same stale pixmap data as described above, but they did have what appeared to be stale window decorations just hanging around behind the window.

I'd be happy to reimplement the cache as part of this patch set, if you'd like. Without changes to x.c though, just enabling 32-bit visuals everywhere doesn't seem to be enough to make transparency work properly.

[stapelberg]

Replying to comment 10 by kemurphy:

I'd be happy to reimplement the cache as part of this patch set, if you'd like. Without changes to x.c though, just enabling 32-bit visuals everywhere doesn't seem to be enough to make transparency work properly.
Yes. We are not going to lose the cache over transparency support :).

[i3bot]

[Original comment by geyslan@…]

Hi, I reproduced the same behavior. I'm using xompmgr in .xinitrc just before exec i3. Why? I want real transparency using uxrvt and some fading that avoid vsync tearing. To redraw the messed up window, just after the vertical splitting, I do mod+vertical again. It's a way.

[i3bot]

[Original comment by geyslan@…]

I have to add that using xcompmgr the drawing is much faster.