Some windows are not displayed after reloading i3

[link1375]

Hi,

I am using arch with i3 and wanted to apply blur in combination with transparency. Everything works fine, but if I reload i3 (mod+Shift+r) windows are not properly displayed anymore. The same occurs with the normal compton package. To test if this a general problem for my configuration I installed xcompmgr and there is no problem. Also compton outputs a lot of Bad Window erros. After killing the compton process all windows are displayed but obviously without transparency. Starting the process again leads to the same problem.
I could not determine which applications are affected since e.g. firefox is displayed on one workspace but not on another.
As suggested by tryone144/compton#11 (comment) killing compton, reloading i3 and restarting compton does work.

[yshui]

Might be the same bug as #134

[link1375]

Maybe, but I don't have problems with sleep/wake up. Multihead did I not test yet.

[yshui]

BTW, which version of compton are you using? Could you try building from the next branch and see if this problem still happens?

[link1375]

Currentyl I am using compton-tryone. I installed this and your version via AUR.

[morgoth6]

I have similar problem using i3 some time ago. Additionally with flashing portions of already displayed windows and missing text in urxvt. No time to bisecting it now, but current next with reverted 4205ee5 seems to cure it for me.

[yshui]

@morgoth6 Can you capture a trace?

[morgoth6]

@morgoth6 Can you capture a trace?

Sorry for delay. I can try, but is there a way to trigger trace at runtime ? (signal, hotkey ?) This problem does not appear always/immediately (to be more acurate it's hard to spot sometimes) and it may be hard to catch short capture. It seems to happen more frequently when URXVT with some tabs open and when Virt-viewer, but this can be contingency only.

For now today's build still works with this commit reverted. I will try with pure build in a moment.

[yshui]

@morgoth6

but is there a way to trigger trace at runtime ?

This is not possible with apitrace.

BTW, if you are going to capture a trace, please remember to use --log-level=trace when doing that.

[tryone144]

The workaround highly suggests this is indeed a duplicate of #134.
If this can still be reproduced with the current next, feel free to re-open and provide more details.