Subject: FVWM: Slow moving of XMMS window in fvwm 2.5.1

From: Marcus Lundblad <[email-masked]>
Date: Wed, 1 May 2002 17:04:21 +0200 (CEST)

I compiled fvwm 2.5.1 and now it feels as xmms's window is moving more
sluggish than before (2.5.0). I have OpaqueMoveSize unlimited.
But even setting OpaqueMoveSize 0 doesn't make any difference.
(and xmms does it's own window management).

Is this a common problem?

//Marcus

--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "S. Anderson" <[email-masked]>
Date: Wed, 1 May 2002 11:19:45 -0600

> Is this a common problem?

This seems to have been mostly fixed in the cvs version.

sa

---

From: "S. Anderson" <[email-masked]>
Date: Wed, 1 May 2002 11:31:18 -0600

> This seems to have been mostly fixed in the cvs version.
hmmm, but when I open the xmms playlist it is still pretty bad.

---

From: Andre Bonhote <[email-masked]>
Date: Mon, 6 May 2002 08:55:34 +0200

> hmmm, but when I open the xmms playlist it is still pretty bad.

Umm, and there's about the same problem when I detach GTK/Gnome button
bars. When I drag them using Gnome's handle, the window is far behind
the mouse arrow. Using my titlebar to move the window, or fvwm's Move
function, it works fine.

I am using today's CVS version.

CU&HAND

A.

-- 
Real programmers use "cat > a.out"

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 7 May 2002 13:22:36 +0200

> the mouse arrow. Using my titlebar to move the window, or fvwm's Move

I have committed a patch that circumvents the problem, but I think
there are bugs in both, GTK and XMMS.  When fvwm gets a
ConfigureRequest from an application (for example when the
application moves its own window), fvwm looks for follow up
ConfigureRequests on the event queue that override previous ones.
In order to give applications a chance to generate these events, I
had a small pause at the beginning of the event handler that was
meant to allow the scheduler to run these applications:

  /* Free some CPU */
  usleep(1);

I don't know how it does that, but xmms seems to synchronize with
fvwm by waiting for the ConfigureNotify response and then issues
configure requests that have become obsolete already.  Normally,
fvwm would filter out multipe CR events, but during window motion,
it never has more than one on the queue at the same time.  I can
only guess that there is some very funny logic in GTK (XMMS is a
GTK application) that forces this performance hog situation.  It
probably has something to do with calling XSync() after
XMoveWindow().

Could someone report this to the GTK folks please?  With my patch
this is gone away, but it's no real fix because it will surely
break something with other types of applications.  To reproduce
the problem, the 2.5.1 release should do.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].