Re: FVWM: Slow moving Gnome Button Bars in 2.5.2 (Was: Slow moving of XMMS window in fvwm 2.5.1)

From: Dominik Vogt <fvwm_at_fvwm.org>
Date: Tue, 7 May 2002 13:22:36 +0200

On Mon, May 06, 2002 at 08:55:34AM +0200, Andre Bonhote wrote:
> On Wed, May 01, 2002 at 11:31:18AM -0600, S. Anderson wrote:
> > On Wed, May 01, 2002 at 11:19:45AM -0600, S. Anderson wrote:
> > > On Wed, May 01, 2002 at 05:04:21PM +0200, Marcus Lundblad wrote:
> > > > 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).
> > >
> > > This seems to have been mostly fixed in the cvs version.
> > >
> > 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 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: d.vogt_at_lifebits.de
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue May 07 2002 - 06:34:55 BST

This archive was generated by hypermail 2.3.0 : Mon Aug 29 2016 - 19:37:53 BST