Subject: Notification: incoming/710

From: [email-masked]
Date: Thu, 03 May 2001 18:52:32 -0500

FVWM Bug Tracking notification

new message incoming/710

Message summary for PR#710
	From: [email-masked]
	Subject: Slowdown while moving windows :-(
	Date: Thu, 03 May 2001 18:52:31 -0500
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

>From [email-masked] Thu May 03 18:52:32 2001
From: [email-masked]
To: [email-masked]
Subject: Slowdown while moving windows :-(
Date: Thu, 03 May 2001 18:52:31 -0500

Full_Name: Marc-Jano Knopp
Version: 2.3.31
CVS_Date: 
OS: GNU/Linux 2.4.2
X_Server: XFree86 4.0.2
Submission from: (NULL) (145.253.20.218)

As I am lazy, I defined a few useful key+mouse bindings
a few years ago (fvwm 1.xx). One of these bindings is:

  Mouse   1       WTFS    M       Move
  (Press [Alt] and then mouse button 1 anywhere inside a
   window to move it)

Besides the desired effect of not having to point exactly
to the title bar to move a window, moving windows is notably
FASTER than the normal way of moving it by dragging
its title bar.

This is true for

  - vtwm
  - fvwm 1.xx
  - fvwm 2.2.4
  - fvwm 2.2.5
  - probably ALL window managers

but NOT for fvwm 2.3.31.

Moving windows using Alt-Mouse 1 inside a window is as
slow as moving it by dragging the title bar :-(

The symptom of slow (actually jerky) window movement
when using the title bar is maybe due to masking
the mouse cursor over the background for some reason,
although that would not be necessary, as the standard
mouse cursor should only extend to the right and to
the bottom, i.e. over the window, and NOT over the
background.  An evidence for this assumption is that
Alt-Mouse 1 lets you move windows smoothly only when
the pointer had a certain minimum distance to the
border before you clicked button 1. If the pointer
is too close to the border, then even using Alt-Mouse 1
for moving windows is jerky.

This is true for both hardware and software cursors
(configured via the appropriate XFree86 option).

So here are my requests/suggestions:

1) _PLEASE_ fix that bug! (It is one, isn't it? Don't
   tell me it _has_ to be that way, coz then I won't
   see another day :-(

2) While you're at it, could you also try to think of
   a way of fixing this behavior for normal window
   movement (by using the title bar)? There seems to
   be no reason for this behavior, it is most likely
   a bug - but maybe in XFree86...

It gives me strange feelings to see that Windows 98
lets me move windows very smoothly... although not
synch'ed to the VBI (just like Linux/X :-(

Best regards,

  Marc-Jano

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

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 4 May 2001 11:00:25 +0200

>   - probably ALL window managers

    - fvwm 2.3.31

For me there is indeed a noticeable difference (moving an rxvt
window with an xpm background).

> background.

Fvwm does not draw the mouse cursor itself.  This is the task of
X11.  If there is a performance problem, then it has to be fixed
in X.  In general, moving windows with 2.3.x is slower than
previous versions because fvwm does more things in the motion
loop than in the past.

> An evidence for this assumption is that

I can verify this, but as I said before, there is nothing we can
do about it since the responsible code is not part of fvwm.

>    a bug - but maybe in XFree86...

There are a number of things that affect the speed of window
movement.  First, the geometry window in the center of the screen
obscures parts of the moved window which slows things down.  You
can put this window in the top left corner of the screen with

  Emulate Fvwm

Or disable it completely with

  HideGeometryWindow Move

Second, try to turn the BackingStore and SaveUnders features on
and off.  Most modern graphics cards can write data much faster
than read it, so it's often better to let the application redraw
the obscured area than let the X server cache it.  Try

  Style * BackingStoreOff, SaveUnderOff

and

  Style * BackingStore, SaveUnder

and see which gives you better performance.  The default setting
depends on the X server (XFree 3 does backing store per default,
XFree 4 does not).  Next, all drawing directives to the X server
go over the network.  To make sure the packets are delivered
locally on your machine, set your DISPLAY variable appropriately:

  export DISPLAY=":0.0"

Do *not* put a host name in front of the ':'.  If you do, packets
are actually sent over the network adapter (if you have one).
Other reasons for jerky movement can be Snap Attraction and
paging during movement.  Turn them off explicitly if you don't
need these features:

  SnapAttraction 0

and

  EdgeThickness 0

to disable paging completely, or

  EdgeResistance 10000 <any value>

to disable only paging during window movement.  Another thing you
could try is to disable the mouse cursor during window movement:

  CursorStyle Move None

or if you want it only for Alt-Button1:

  AddToFunc MoveWithoutCursor
  + I CursorStyle Move None
  + I Move
  + I CursorStyle Move

  Mouse   1       WTFS    M       Function MoveWithoutCursor

Also, it may help to use only simple, flat decorations on the
title bars, buttons and borders to keep redraws simple.

> synch'ed to the VBI (just like Linux/X :-(

The reason is probably that some day in the past the X consortium
decided that X was good enough and did not need much improvement
anymore while M$ kept tuning their system :-(  And then, many
graphics adapters don't have good drivers for XFree.  I have been
using the non-accelerated SVGA driver for ages now.

Hope this helps

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-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]