richardgv
commented
10 years ago I'm sorry for the late reply, gensenio, firstly.
I looked into the source code of icewm-1.3.8. I believe the code drawing the window resize/move frame isYFrameWindow::drawMoveSizeFX() (src/movesize.cc, line 182). Essentially it directly draws a frame on root window. Unfortunately, compton draws to the root window, too! (With --paint-on-overlay, compton draws to the X Composite overlay window, but seemingly the result is then copied to root window, or something.) Just as it won't work really well if two painters are drawing onto the same spot on the canvas, two programs drawing to the same window is not guaranteed to bring the correct result. And if one program uses X core graphics while another uses OpenGL, things may get even worse, and that is the right the case you have encountered. So, it's perfectly sane that compton doesn't cooperate with icewm's drawing onto the root window, and I'm not aware of a way to perfectly deal with the issue unless you wish to modify the source code of IceWM. (And, the safe way to draw such a frame -- which is the method xfwm4 uses -- is to create a special frame window when you need to do so.)
You may try --paint-on-overlay, nonetheless, to see if it brings you any luck.
By the way, icewm-1.3.8 + compton + nvidia-drivers-340.24 doesn't exhibit the issue here, but weirdly enough, it happens on fvwm, which uses basically the same technique to draw the window move/resize frame.
icewm window resize and window move rectangles are not always shown when opaque move and opaque resize are disabled and glx backend is used.
no issues with xrender backend.