Window dragging latency


#1

When dragging a window, I have to wait about 2 seconds doing nothing (just pressing the left mouse button), before the window starts moving. Before that, it just stays at the old position.

I have located the problem to be that no XEvent is sent at all when starting to drag a window, although at least configurenotify events should have been sent.

I gather this could be a window manager bug, but I’m using the fvwm window manager, which is extremely old and trusted, so I’m kind of doubting that. I haven’t seen this problem in other programs either. But on the other hand, when trying gnome (I think it use sawfish?), dragging works fine. I haven’t tried any other window managers.

The problem doesn’t appear when using the native window title bar, or by dragging using letf alt + mouse.

Any ideas what might be the problem? I would very much like this problem to go away, because it seems like the program is freezing when the window is not moving.

If it is an impossible problem to solve (or at least very hard). would it be much work to detect at startup whether the problem will appear, and in case force use of native window title bar?

What happens in other window managers?


#2

Bizarre. Must be a window manager strangeness, though I don’t have fvwm so haven’t seen it myself. When you drag with a non-native title bar the code just moves the window to a new location each time the mouse moves; it doesn’t use any standard dragging events, but why the WM would just ignore these calls to change the window location is a mystery!


#3

So are you saying that juce takes over dragging handling? Can you point me to the lines where window moving handling is happening? I might stumble over something by inserting some debug printing here and there…


#4

Seems like adding an XUngrabPointer( display, CurrentTime ) before XMoveResizeWindow makes the window move. The problem then is that if I drag too fast, the window slips.

I think, however, the solution lies in using the _NET_WM_MOVERESIZE hint. And I tried that, copying code from xmms, but since use of _NET_WM_MOVERESIZE also requires the pointer to be ungrabbed, the window still slips, so no improvement.

Do you know if there is there a way to still keep focus and everything, while ungrabbing the pointer?


#5

So if mouse-grabbing is on, then calls to move the window don’t have any effect… why??? It must be deliberate on the part of the WM, but I just don’t see the point.

Don’t know of any other way to keep hold of the mouse without grabbing it. There must be some way to force the WM to do what it’s told…[/quote]


#6

I am not quite sure why it is happening. Maybe one of these, or both, of the following threads are correct:
http://www.mail-archive.com/fvwm@lists.math.uh.edu/msg10152.html
http://www.mail-archive.com/fvwm@hpc.uh.edu/msg04782.html

As you see, gkrellm has the same problem. And its not fixed, so its no use to look at gkrellm’s source.

Xmms, on the other hand, does not have this problem, and it use _NET_WM_MOVERESIZE messages to move and resize the windows instead of XMoveResizeWindow. I guess careful study of xmms’s source could be a good idea.


#7