After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 156543 - Wireframe mode can result in left-behind artifacts under multiple circumstances
Wireframe mode can result in left-behind artifacts under multiple circumstances
Status: RESOLVED OBSOLETE
Product: metacity
Classification: Other
Component: general
2.16.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
: 161239 329980 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-10-27 03:42 UTC by Havoc Pennington
Modified: 2020-11-06 20:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
lame patch (982 bytes, patch)
2004-10-27 03:43 UTC, Havoc Pennington
needs-work Details | Review
suggested patch (1.01 KB, patch)
2008-05-22 08:19 UTC, Chris Wang
reviewed Details | Review

Description Havoc Pennington 2004-10-27 03:42:57 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.
Comment 1 Havoc Pennington 2004-10-27 03:43:49 UTC
Created attachment 33101 [details] [review]
lame patch
Comment 2 Elijah Newren 2005-01-08 02:03:20 UTC
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.
Comment 3 Elijah Newren 2005-01-10 15:52:34 UTC
See also bug 161239.
Comment 4 Elijah Newren 2005-03-16 23:46:56 UTC
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.
Comment 5 Elijah Newren 2006-02-06 21:40:32 UTC
*** Bug 161239 has been marked as a duplicate of this bug. ***
Comment 6 Elijah Newren 2006-02-06 21:40:49 UTC
*** Bug 329980 has been marked as a duplicate of this bug. ***
Comment 7 Elijah Newren 2006-02-06 21:42:07 UTC
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.
Comment 8 Sebastien Bacher 2006-09-30 12:13:43 UTC
Still happening with GNOME 2.16.0. Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/13521
Comment 9 Chris Wang 2008-05-22 08:15:40 UTC

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.
Comment 10 Chris Wang 2008-05-22 08:19:28 UTC
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
Comment 11 Sascha Heid 2009-10-07 01:34:44 UTC
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?
Comment 12 Fabio Durán Verdugo 2010-12-13 02:43:16 UTC
any news for this report/patch ?
Comment 13 Thomas Thurman 2011-01-19 01:21:09 UTC
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.)
Comment 14 Thomas Thurman 2011-01-19 01:21:13 UTC
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.)
Comment 15 André Klapper 2020-11-06 20:06:07 UTC
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.