Context: there is a user reporting to compton (some kind of X11 compositor) complaining that, with compton fade out is enabled, minimizing a window will cause the body of the window to disappear immediately, then the decoration of the window will gradually fade out. The way compton handles fade out is like this: when a window is unmapped, compton will keep using the last named pixmap right before the unmap, and draw it will decreasing opacity. Therefore, I suspect xfwm might did something during window unmap so the body of the window disappeared. I understand this might not really be a bug in xfwm, but I wish you could shed some light on this problem, as this only occur when compton is used with xfwm.
(In reply to yshuiv7 from comment #0) > > I understand this might not really be a bug in xfwm, but I wish you could > shed some light on this problem, as this only occur when compton is used > with xfwm. I cannot speak about compton, but I can explain about the xfwm4 own compositor (if you use compton, then better ask compton devs). Compositing is achieved because the X11 server (Xorg) does not draw directly to the screen but instead draw window ontents to a pixmap offscreen, the compositor then "composes" the final image on screen out of those pixmaps. In X11, there is no actual "iconify" state, it's just the window manager who "unmaps" the client window. When a window is unmapped, there is no content anymore and no offscreen pixmap allocated either. So the updates of the window content won't show. Some compositor will keep the last valid pixmap for as long as the the window is unmapped, but the content will not change anyway, it's just a static copy of the state of the window at a given point in time. Some other window manager/compositor such as mutter will not unmap the client window, just move it behind a fullscreen window so that the backing pixmap remains allocated and updates from the client can be captured, but that causes other issues with clients that actually expect their window to be unmapped with iconified. xfwm4 simply uses a copy of the offscreen pixmap for as long as their is one, and won't keep a copy if the offscreen pixmap is destroyed when the window is unmapped. Whatever compton does is compton's problem.
I am the compton dev. And we _are_ using the last valid pixmap before unmap. The problem is the body portion becomes transparent when window is unmapped, and this only happens with xfwm. So I wonder if that's because xfwm does things differently or something.
(In reply to yshuiv7 from comment #2) > I am the compton dev. And we _are_ using the last valid pixmap before unmap. Then what becomes transparent? Whatever was saved before the unmap remains and Compton would keep using that as long as the client window is unmapped. > The problem is the body portion becomes transparent when window is unmapped, Body, you mean the client area? The window manager doesn't do anything to the content, it just unmaps the client window. Once unmapped there are no more updates (as there is no more content) so I don't understand how the window manager could come into play there. > and this only happens with xfwm. So I wonder if that's because xfwm does > things differently or something. Considering Compton is a separate compositor from the window manager, it deals directly with the Xserver and the composite extension, the window manager is not involved here. If Compton saves the last known pixmap before unmap, and uses it, how the body could become transparent? I'm not sure I understand what you mean, I'm afraid.
> If Compton saves the last known pixmap before unmap, and uses it, how the body could become transparent? I have zero idea either. Also, I just noticed this only happen with 32bit depth windows. If you cannot grasp the symptom I was describing, you can see the attached video clip.
Created attachment 8256 video clip of the problem
You might need to single step through the clip to see it.
Possibly because xfwm4 unmaps the client window before the frame?
Olivier Fourdan referenced this bugreport in commit 63a797b13023394937a89b41708e40d11b8fa5b2 client: Withdraw the frame before the client window https://git.xfce.org/xfce/xfwm4/commit?id=63a797b13023394937a89b41708e40d11b8fa5b2
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/317. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev