Root window not redrawn

[raboof]

I have a window manager that leaves the root window untouched (I think, it's Notion), and put a background picture on it with wmsetbg.

When I run compton, the root window is no longer redrawn, and just shows whatever was last drawn on that location - e.g. the windows from the previous workspace or a window that has since been resized or moved away.

This is quite possibly not a compton issue, but perhaps you can point me in the right direction. Who is responsible for redrawing the root window and when?

(this issue was reported to the notion bugtracker as https://sourceforge.net/p/notion/bugs/73/ )

[raboof]

Probably not a compton issue: we put a window between the root window and the client windows (so we can e.g. easily move 'm all to another output if neccessary), and it appears that this is what's causing the issue.

[richardgv]

@raboof:

Sorry for the late reply, firstly.

1. Compton is responsible for painting the contents of the root window. It looks for an X pixmap in the property _XROOTPMAP_ID or _XSETROOT_ID of the root window, and uses it as the wallpaper. When not found, it draws the background in gray.
2. As what you indicated, the issue would most likely occur if you have a child of root window on background that doesn't correctly repaints itself, and this is not our problem.
3. Unfortunately, window managers like notion are not suitable for use with compton (and probably, many other compositors), because it creates a virtual root window under the real root window and places the client windows as sub-windows of the virtual root window, which is not the optimal situation for a compositor to manage.

[raboof]

No problem, thanks for the confirmation!

As you can imagine avoiding putting an 'intermediate' Notion workspace window between the root window and the client windows would be tricky.

I've briefly looked into setting the opacity of the 'intermediate' window to 0%, but it seems that also affects the client windows - so that doesn't seem like a useful approach.

Another way might be to tag 'intermediate' windows with some X property and patch the compositor to recognize (and ignore/skip) those windows. Does that make any sense? Do you know of any compositor that does something like that?

[richardgv]

Sorry, apparently I misunderstood the problem because I didn't read the SourceForge bug report.

1. Notion uses a virtual root window to manage client windows. Essentially this means all client windows have one common ancestor that is not the root window (but a subwindow of the root window). Compton (and probably many other compositors) cannot manage the situation: In compton's perception, that's (usually) one and only one client window, the virtual root window. Compton still works in the case, but almost all window effects are broken.
2. It's nontrivial to add support for virtual root windows: Separation of the real root window and the virtual root window, multiple virtual root windows, override-redirect windows under the real root window, the stack order of client windows under the real root and virtual root windows and the virtual root window itself, window moving between virtual root windows, etc., are all annoying things that must be taken care of. (And most likely the thing would still be broken if we add support for virtual root windows, since it really is a problem of notion and X, I suppose.)
3. Simply hiding the virtual root window (or the "intermediate" window as you say) is not going to work because most client windows are children of the virtual window.
4. As far as I could see, notion-3_p2013030200 uses ParentRelative background pixmap for transparency (see debrush_enable_transparency() in de/draw.c). For some reasons the Picture of the window given by X doesn't contain the correct content in the case when composition is enabled (but it does look correct when composition is disabled). I have found no related documentation about this effect so far. (X is pretty badly documented, heh.) I have found no easy workaround on the compton's side so far.
5. Maybe calling XClearWindow() from the WM (notion) after a layout change and repaint would be the right fix?

Another way might be to tag 'intermediate' windows with some X property and patch the compositor to recognize (and ignore/skip) those windows. Does that make any sense? Do you know of any compositor that does something like that?

They are already "tagged" as _NET_VIRTUAL_ROOTS property on the root window. But as described above, your proposal won't work as expected.