#622 Outline when moving a window not working with the taskbar

[Anonymous]

Whenever I grab a window to move it, and the outline of
it shows up, if this outline overlaps the taskbar when
I drag the window to the edge of the screen (and it
switches workspaces) the window and the mouse get
teleported to the other side of the screen (as
expected) but there is a remenant of the window outline
still on the taskbar, as it was just before the swap.
If I switch workspaces again, this remenant just
dissapears.

[Mark Tiefenbruck]

Logged In: YES
user_id=1538990

There are much weirder things that happen with those
outlines, but apparently they look terrible if you fix it.
You'll just have to live with it. If you have some resources
to spare, you can turn on "opaque window moving" instead.

[Thomas Luebking]

Not reproducible for me. Neither with nor without compositor.

[Thomas Luebking]

Ok, is reproducible (though in different context and trigger)

The problem is that the outline is implemented as XOR paint on the root and all subwindows.
This relies on a static context, ie. no repaints other than the outline (and overlays) at all.
Fluxbox establishes a server grab to guarantee this, but while holding the grab, itself can still repaint its windows (titlebars, toolbar, ... and a recent patch accidentally breaks the grab on workspace switches ... eeheee...), so what happens is:

1. draw XOR'd outline
2. the window updates, the outline is gone in that area
3. draw XOR'd outline to erase the former draw (XOR ...)
4. the outline was not removed but actually just added on the window which has a clear area for step #2

There won't be a simple resolution for this. Maybe one could simply add an unmanged window on top of things, have it inherit the background (ie. display a snapshot of the screen when added) and paint into this.

"Interestingly", the resize outline does not grab the server, causing such artifacts more or less systematically (though usually on repainting windows which will then clear w/ their next update. In the end, the outline seems absent from such windows)

=> maybe stop grabbing the server for the moves as well and instead cause a global exposure when finishing move & resize (map/unmap a root size window, ie. what xrefresh does)??

[Mark Tiefenbruck]

For what it's worth, the resize outline doesn't grab the server because
people can take a while to resize their windows, and it's kind of rude to
grab the server for that long. For instance, users complained that their
videos would stop playing. Indeed, there is not a simple resolution for
this. Whatever we do, though, we should probably do the same thing for
resizing and outline moving.

On Wed, Sep 7, 2016 at 12:34 PM, Thomas Luebking <baghira-style@users.sf.net

wrote:

Ok, is reproducible (though in different context and trigger)

The problem is that the outline is implemented as XOR paint on the root
and all subwindows.
This relies on a static context, ie. no repaints other than the outline
(and overlays) at all.
Fluxbox establishes a server grab to guarantee this, but while holding the
grab, itself can still repaint its windows (titlebars, toolbar, ... and a
recent patch accidentally breaks the grab on workspace switches ...
eeheee...), so what happens is:

1. draw XOR'd outline
2. the window updates, the outline is gone in that area
3. draw XOR'd outline to erase the former draw (XOR ...)
4. the outline was not removed but actually just added on the window
   which has a clear area for step #2

There won't be a simple resolution for this. Maybe one could simply add an
unmanged window on top of things, have it inherit the background (ie.
display a snapshot of the screen when added) and paint into this.

"Interestingly", the resize outline does not grab the server, causing
such artifacts more or less systematically (though usually on repainting
windows which will then clear w/ their next update. In the end, the outline
seems absent from such windows)

=> maybe stop grabbing the server for the moves as well and instead cause
a global exposure when finishing move & resize (map/unmap a root size
window, ie. what xrefresh does)??

---

• [bugs:#622] https://sourceforge.net/p/fluxbox/bugs/622/ Outline when
  moving a window not working with the taskbar*

Status: open
Group: future release
Labels: Interface (example)
Created: Mon Jul 17, 2006 09:20 AM UTC by Anonymous
Last Updated: Wed Jul 06, 2016 04:37 PM UTC
Owner: nobody

Whenever I grab a window to move it, and the outline of
it shows up, if this outline overlaps the taskbar when
I drag the window to the edge of the screen (and it
switches workspaces) the window and the mouse get
teleported to the other side of the screen (as
expected) but there is a remenant of the window outline
still on the taskbar, as it was just before the swap.
If I switch workspaces again, this remenant just
dissapears.

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/fluxbox/bugs/622/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Thomas Luebking]

Not hiding the moved window on workspace swaps reduces the artifacts vastly.

diff --git a/src/Screen.cc b/src/Screen.cc
index 1714ffd..349633b 100644
--- a/src/Screen.cc
+++ b/src/Screen.cc
@@ -967,7 +967,7 @@ void BScreen::changeWorkspaceID(unsigned int id, bool revert) {

     FluxboxWindow *focused = FocusControl::focusedFbWindow();

-    if (focused && focused->isMoving() && doOpaqueMove())
+    if (focused && focused->isMoving())
         // don't reassociate if not opaque moving
         reassociateWindow(focused, id, true);

This was more or less the case before commit f3bd8e75 - do you recall the background?
Was it for technical reasons or was hiding the moved window intentional?