Subject: Re: speed (?) of window moves

From: Dominik Vogt <[email-masked]>
Date: Sat, 14 Aug 1999 02:23:45 +0200

On Sat, Jul 17, 1999 at 03:47:38PM -0700, Amir Chossrow Akhavan wrote:
> Hi!
> 
> I've noticed it for some time, but thought it might be the price I
> have to pay for fancy decorations: 
> Window movements are not smooth, it's more a jumping from point to
> point, everything looks like on a butt slow machine. 
> It's really bad for opaque moves, but the rubberband movements are not
> convincing either.
> My box has reasonable speed, graphics board, and RAM (Celeron 400A,
> 384MB, Millennium 2 PCI with 12 MB WRAM), and in fact if I start KDE, 
> or enlightenment, the window movements are smooth with immediate response.
> 
> I've tried a number of things like renicing fvwm2 or
> using real time scheduling, but nothing helps.
> I've also run fvwm2 with default window styles (no pixmaps at all),
> but it doesn't make a difference (as it ideally should not ;) ).
> Also, playing with various style settings didn't seem to help at all.
> 
> I accidentally started into fvwm (1.xx) today and noticed that its
> really VERY fast compared to fvwm2. 
> 
> Another thing I've found is that windows without decorations (like
> x11amp, or a borderless and transparent Eterm) show much smoother opaque
> moves than windows with deco (but again independent of the presence of
> pixmaps in the window border decorations). 
> Also, windows of applications which geometry settings are defined in
> lines and chars, not in pixels, are particularly slow (e.g. xterm,
> or emacs, as opposed to xview).
> The faster the moves, the less smooth the moves get.
> 
> Interestingly, when I run fvwm2.2 (not CVS because of xpm-lib 
                                ^^^

2.2.0 or 2.2.2?

> incompatibilities) on a really slow DEC 3000, movements appear much
> smoother.
> 
> Is there a philosophy behind this?
> I thought the idea could have been to prevent the usual tear-off effects
> because X cannot easily synchronize its events to the vertical retrace
> of the monitor electron beam (and uses double buffering instead). 
> But I don't really have a clue about this ;)

Could you please try to narrow down where this problem occured first
(2.3.0 to 2.3.6). I have just written a new configure option
--enable-move-bug-workaround that may have an impact on the problem.
Can you try this too?

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Amir Chossrow Akhavan <[email-masked]>
Date: Mon, 16 Aug 1999 23:21:08 -0700 (PDT)

On Sat, 14 Aug 1999, Dominik Vogt wrote:

> >  < snip>

Hi!

First, I'm not shure if I really activated the configure switch for 
the move-bug-workaround. I can't see any obvious differences between
versions compiled with switches manually turned (presumably) on or off. 
Which one of the scripts am I supposed to change?

But I've done some vigorous amateur testing, and I think I found
something interesting.  This clumsy window jumping is more obvious
when you move the window with mouse pointer grabbing it at its borders
or the title bar.  pushing is very often worse then pulling e.g., you
move the window to the right with the mouse located at the left border
       ___________ 
      |=titlebar==| 
mouse->           | => move to the right 
      |           | 
      |           | 
       ----------- 

I think the problem is that the location of the mouse pointer relative
to the window changes during moves, that is, it is situated inside the
window for some time, then outside of the window for some time. 
This interferes with the redrawing process. When the mouse pointer 
is situated well inside the window, the moves will be much smoother. 
This also explains why the jumping is worse during fast moves.  
So it might help to hide the mouse pointer during moves, but that 
of course might look strange, too.

Still, there are differences between different applications and how
they behave under fvwm and fvwm2.  I can't see too much differences
between 2.3.7, 2.2.2, and 2.2.0, though, it would really be necessary
to quantify the effects, and I have no clue how to do that.

I've just picked out some apps and describe their behaviour with
opaque moves.  All windows are 400x400 pixels wide (except x11amp, and
kcalc which can't be resized)

fvwm2.3.7 / fvwm2.2.2 / fvwm2.2.0 
=================================

xterm, eterm, xview: ok, but not as smooth as under fvwm 
kfm, emacs: clumsy 
kcalc, gnomecalc: very clumsy 
x11amp: horizontal moves ok, vertical moves clumsy 
filerunner: clumsy

Things seem to be a little worse if Esetroot was used to set the
background image.

fvwm 
==== 

xterm, eterm, xview: smooth 
kfm, emacs: a little clumsy
kcalc, gnomecalc: clumsy 
x11amp: horizontal moves ok, vertical moves clumsy 
filerunner: clumsy when mouse pointer is well inside window,
            really bad when mouse pointer is placed on borders
            worse than under fvwm2.3.7

maybe I'm just too picky ;)

have a nice day and thanx, 
amir

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 17 Aug 1999 10:41:25 +0200

> Which one of the scripts am I supposed to change?

You will see it the switch has been activated in config.h. If it is,
the DISABLE_CONFIGURE_NOTIFY_DURING_MOVE macro must be defined.

> fvwm2.3.7 / fvwm2.2.2 / fvwm2.2.0 

That's *weird*. Please try this configure option mentioned above
and then try using the 'emulate fvwm' command (this puts the
feedback window in the top left corner of the screen, so it should
not obscure the window being moved so often). Perhaps it's a problem
of the backing storage of the feedback window. Please make sure
you're running your X server with backing storage enabled. With
Xfree you have to start it with 'startx -- +bs' to do this.
 
I notice a substantial improvement with the 'emulate fvwm' line.

> maybe I'm just too picky ;)

No.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
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: Tue, 17 Aug 1999 18:42:25 +0200

> Xfree you have to start it with 'startx -- +bs' to do this.
                                   ^^^^^^^^^^^^^

Sorry, wrong option. Use 'startx -- -wm'.

Bye

Dominik ^_^