Outline when moving a window not working with the taskbar

[sillysloft]

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.

Reported by: *anonymous

[sillysloft]

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.

Original comment by: mark-t

[sillysloft]

• Group: v1.3.5 --> future release

Original comment by: akir

[sillysloft]

Not reproducible for me. Neither with nor without compositor.

Original comment by: baghira-style

[sillysloft]

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)??

Original comment by: baghira-style

[sillysloft]

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/

Original comment by: mark-t

[sillysloft]

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?

Original comment by: baghira-style