Unagi Compositing Manager

unagi-0.3 and the current git version fail to render a window correctly on my fvwm 2.6.3 after I move the window when I'm using the default window movement method in fvwm.

Basically fvwm provides two window movement methods: "traditional rubber-band outline" movement and opaque movement. Opaque movement is how most modern window managers behave: When the user uses a mouse to drag a window, the window's content gets moved altogether. The traditional method is, however, displaying an outline showing to where a window will to be moved when the window is dragged, and only actually moving the window's content after the user releases his mouse button. The traditional approach is default behavior in fvwm (as it probably did not change its behaviors much since it was forked from twm in 1993...) and theoretically could save some CPU cycles.

Unfortunately I found unagi feels uncomfortable when dealing with the traditional window movement in fvwm (which I have gotten used to). After a window is moved, if I have unagi running, some parts of the window does not get rendered. The attached file unagi-fvwm-trad-movement-issue.png shows what happens after I move the urxvt window in the middle.

When the problem appears unagi also prints some warning messages about CompositeNameWindowPixmap and such. The output of unagi (built with the debugging option) is attached. You could use "grep -v DEBUG" to find out the warning messages.

Fvwm by default uses a similar mechanism when resizing a window, so the problem appears after a window resize, too.

This is not a very important problem after all. Fvwm does not have many users currently, and will never have many. Thus low in priority.

By the way, seemingly unagi works pretty well in Openbox, and I'm glad to see there's an alternative to the broken xcompmgr or memory-hogging cairo-compmgr.