Root window artifacts with openbox animated iconify and shaded windows

[jvvv]

I'm not sure this is caused by compton or openbox, or it might be a problem in my X configuration. When I iconify a window and openbox's animateIconify option is set, I get this kind of result:

http://goput.it/f50.jpg

This can be worked around by unsetting the animateIconify, so no big deal.

When I shade a window, I get this kind of result:

http://goput.it/gc1.jpg

The shaded window starts as just a box where the window was, then if I move the shaded window's title bar around, I get the displayed artifacts seen.

I can live with this for now and otherwise no problems. I really like compton, so it's not a show stopper. But I would like to get it sorted out, eventually. If you're really busy but can give me any ideas for where to look for the problem, that would be great.

Thank you, John

[segrived]

can confirm this problem

[chjj]

I can't seem to reproduce this on openbox. Do you only see artifacts when the window is above the root window? What root-window-setter/desktop-manager do you use?

[jvvv]

I'm trying to understand what you are asking about the artifacts (I'm trying not to be dense, but I am sometimes). If your asking if I see the artifacts when a different window covers up the root window or at least covers effected part of screen, then no. But also note that I've found that if I drag a window other than one that is shaded, it acts like an eraser to the artifacts. Making any window maximized clears the artifacts, as well.

I've been using feh to set my wallpaper. I tried xsetbg from the xloadimage package and display from imagemagick; these only set the window behind conky's window (wierd). I tried nitrogen, gsetroot, and hsetroot with same results as after feh. (Side note: hsetroot by default draws to both of my screens - nice). So I thought it might help if I have some screenshots without setting the root window at all: http://goput.it/yu4.jpg http://goput.it/6lt.jpg

Also, I use xdm for my display manager. Otherwise, it's just openbox with compton, tint2, conky, xpad, volumeicon, and artha that get started from my openbox autostart file.

Hope this helps Regards, John

[jvvv]

Sorry for closing reopening. Mouse slip.

[chjj]

I'm trying to understand what you are asking about the artifacts

For example, if you drag a window above a web browser window, do you get artifacts? or is it just when you drag it above the root window?

But also note that I've found that if I drag a window other than one that is shaded, it acts like an eraser to the artifacts. Making any window maximized clears the artifacts, as well.

The reason that happens is because that part of the screen is only repainted on a damage event from another window.

Does this always happen, or does it come and go? The million dollar question is, do you experience the same behavior with the original xcompmgr or xcompmgr-dana? That would be a really good way to figure this out. Unfortunately, unless I can get some help on this, it's really hard to fix something if I can't reproduce it.

[jvvv]

On 03/25/2012 02:52 PM, Christopher Jeffrey wrote:

For example, if you drag a window above a web browser window, do you get artifacts? or is it just when you drag it above the root window?

OK, I see what you mean. It only happens to the root window.

The reason that happens is because that part of the screen is only repainted on a damage event from another window.

Does this always happen, or does it come and go? The million dollar question is, do you experience the same behavior with the original xcompmgr or xcompmgr-dana? That would be a really good way to figure this out. Unfortunately, unless I can get some help on this, it's really hard to fix something if I can't reproduce it.

It happens consistently. I tried xcompmgr with various and sundry options. It doesn't happen with xcompmgr, but then I see no trace of transparency, either. The same is true for xcompmgr-dana. Not sure what to think about it. Compton may use a little bit more cpu cycles, but most of the time, I can spare some. I shut off iconify animation and can go on without using window shade/roll up feature. Perhaps this is an Xserver or configuration bug that compton just brings to light.

Thanks for compton and thanks for taking the time to work with me on this.

Regards, John

[bytepossum]

I believe I managed to get rid of minimization artifacts by starting Compton with -S option (synchronous operation).

[jvvv]

On 07/09/2012 01:40 PM, glesik wrote:

I believe I managed to get rid of minimization artifacts by starting Compton with -S option (synchronous operation).

---

Reply to this email directly or view it on GitHub: https://github.com/chjj/compton/issues/17#issuecomment-6853837

Thank you for your input. As it happens, I use that option. But your help spurred me to go through each option I use separately to be sure that I knew exactly which one causes the artifacts. So far it is only the -e option (window frame transparency) that seems to bring about the issue. Thank you very much.

[richardgv]

@jvvv , @glesik , @segrived : Please, if any of you are active, test if this problem exists on a build of current richardgv-dev branch. (master branch is more stable, but there are few changes on richardgv-dev branch that I want somebody to test.) I did not notice this problem on Openbox myself recently.

By the way, compton may throw out a few X errors during window minimization in Openbox. Probably caused by the asynchronous nature of Xlib that I cannot fix. -S is used for debugging and please don't use it for normal usages.

[bytepossum]

I'm using richardgv-dev branch build from Oct 27 now and don't see any artifacts so far too. Openbox 3.5.0 on Fedora 17 here and no -S option when launching Compton. Thanks a lot for the fix!

[richardgv]

@glesik: Thanks for your feedback. But you probably spoke too soon: The problem may already be gone for rectangular windows but still exists on shaped window (like, oclock window) here... I will look into this after I sort out the man pages.

[richardgv]

Huh, please test how thing are going on in Openbox when you do things with shaped windows (oclock, for example) with latest build of richardgv-dev. This sounds like a deeply involved issue:

1. I made some silly mistakes in win_get_region_noframe(), which should only affect users enabling frame opacity;
2. Openbox does not change a shaped window's shape to the correct one after it does shading on the window. (And maybe when it's animating windows, too.) So the window shape reported by X Shape extension is much larger than the window itself, effectively confusing compton.
3. After being shaded a window is 16px high, and Openbox reports in _NET_WM_FRAME_EXTENTS that it has a 16px frame on the top and a 1px frame on the bottom... Silly, huh? Had to use some cumbersome tricks to deal with this...