GNOME Bugzilla – Bug 156543
Wireframe mode can result in left-behind artifacts under multiple circumstances
Last modified: 2020-11-06 20:06:07 UTC
If you have an app (emacs?) that does not repaint on unshade, you can get artifacts left on the app from the unshade wireframe. This patch is a fairly dubious fix for that, I'm not a big fan. But it's in the RHEL package.
Created attachment 33101 [details] [review] lame patch
Cases where I can observe left over artifacts (seem to all involve emacs, since I know I'm more likely to get problems there; note that it's also helpful to have a big emacs window): Case 1: (the case you list, but with instructions since it was hard for me to figure out): 1) Have another window partially overlap the emacs window 2) Shade the window by using the double-click-titlebar-to-shade action (oddly, does not happen with the toggle shade keybinding) Case 2: 1) Have another window partially overlap the emacs window 2) Press alt-click on emacs to raise it (oddly, this doesn't happen with normal click, the raise keybinding, or the move or resize keybindings) 3) Notice that part of the wireframe for emacs is left--and is left in precisely those locations where the first window overlapped it. Case 3: 1) Maximize another window besides emacs (so that it occludes emacs) 2) Unmaximize the other window by double clicking on the titlebar (oddly, this doesn't happen for the unmaximize frame button or the unmaximize keybinding) 3) Note that artifacts are left over from the other windows' wireframe Case 4: 1) Undo the patch from bug 161236 2) Maximize the emacs windows 3) Unmaximze emacs via double-click-on-titlebar (again, Alt+F5 or frame button for unmaximize won't work) 4) Note that artifacts are left over in the emacs window in the area where it occupied before being maximized Here's something interesting that may help somehow. It's a repeat of case 2, but with more detail: 1) Have another window partially overlap the emacs window 2) alt-left-button-press (don't release) on the emacs window to raise it 3) Note that the wireframe isn't shown for the portion of the emacs window that used to be covered by the overlapped window 4) Slowly move the window elsewhere (don't release the mouse button still) 5) Note that the wireframe does fill in--with some extra goodies too... 6) release the left mouse button 7) Notice that part of the wireframe for emacs is left, and in that portion of the emacs window that used to be covered by the overlapped window.
See also bug 161239.
Judging from comments in the patch, the fact that Havoc hasn't applied the patch, and the fact that it only covers one case, I'll mark the patch as needs-work. Kick me if I'm wrong.
*** Bug 161239 has been marked as a duplicate of this bug. ***
*** Bug 329980 has been marked as a duplicate of this bug. ***
The instructions to duplicate in bug 329980 are a little bit different (uses a non-nautilus-drawn-background instead of emacs), showing that this affects more apps out there.
Still happening with GNOME 2.16.0. Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/13521
My evaluation of the problem is metacity fail to track the wireframe during maximization on some transaction stage, to fix the problem from the root require large quantity of code changes. To simplify the problem, we simply end the wireframe when it enter the window_maximize/window_unmaximize code chunck ( note, all listed cases require window to be maximized/unmaximized). This will not cause any performance drawback anyway, since this will have the exact same performance as you click on the maximize button on the upper right corner.
Created attachment 111323 [details] [review] suggested patch As all listed case need to maximize/unmaximize window, to fix the problem in meta_window_maximize/ meta_window_unmaximize can fix all cases
This bug is still not fixed in 2.28. Metacity either shows us some ugly, buggy window-animations or an even buggier wireframe-mode. Why cant we disable both?
any news for this report/patch ?
Review of attachment 111323 [details] [review]: I can't reproduce any of the problems after quite a bit of trying, so I can't test this patch. Can someone tell me how to reproduce it in a current build of Metacity? (Do I need reduced resources on? And yes, I have disabled the compositor.)
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.