Subject: FVWM: Everything stops when moving around windows

From: Tor Stormwall <[email-masked]>
Date: 30 Nov 2002 15:52:05 +0100

Hello!

When I for example play a movie and at the same time moving a window
the movie stops, so do the rest of the screen. Everything stops
completely. After I've moved the window to my wanted location
everything works fine again. 
The problem occurs not only when playing movies but all the times I
move something on the screen.

Do I need a special configuration or something?

I'm using the latest stable release of fvwm2 on a NetBSD 1.6 machine. 

Best Regards,
Tor Stormwall
----------------------
http://creson.com/~tor

--
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: Mikhael Goikhman <[email-masked]>
Date: Sun, 1 Dec 2002 20:53:00 +0000

> I'm using the latest stable release of fvwm2 on a NetBSD 1.6 machine. 

The following should solve your problem:

  OpaqueMoveSize 200

The outline move, although a bit faster, grabs X, so don't use it
if you run "real-time" updating applications (video, monitors).

Regards,
Mikhael.

---

From: Erik Steffl <[email-masked]>
Date: Sun, 01 Dec 2002 23:01:57 -0800

> if you run "real-time" updating applications (video, monitors).

   does outline move have to grab X? it seems like most evil thing (in 
context given context:-), turning nice multitasking system into a one 
task dos piece of crap, even  if it's for few moments only (mostly).

   the move could be excusable but the bigger problem is placement of 
new windows - if you have manual placement, the new window (e.g. browser 
popup add) stops the whole system (well, all X programs) from working. 
that's quite nasty. IIRC the placement of new windows always uses 
outline so your workaround wouldn't work. [yes, I know I can disable 
popups:-) that's not the point]

   OT: am I the only one (ignorant of details of X internals:-) wishing 
grabbing the server was not introduced at all?

	erik

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 2 Dec 2002 10:37:56 +0100

> task dos piece of crap, even  if it's for few moments only (mostly).

The reason is mainly backward compatibility.  We could also draw
the wire frame into separate windows and fill it with a pattern
that gives a good contrast.  But we could not have the current
"Xor" effect.

> popups:-) that's not the point]

In Windoze, they have "solved" the problem by simply aborting
moving/resizing when a new window appears.  Personally I wonder
why people want manual placement at all.  I think it is a big
nuisance.

> grabbing the server was not introduced at all?

Sometimes it can hardly be avoided, but I agree that grabbing the
server for more than a few milliseconds is not such a good idea.
The whole "grabbing" implementation (server, keyboard, mouse) is
flawed and a rich source of problems.  It is definitely overused
in fvwm and probably in many other window managers and
applications too.

Bye

Dominik ^_^  ^_^

---

From: Erik Steffl <[email-masked]>
Date: Mon, 02 Dec 2002 08:39:57 -0800

> that gives a good contrast.  But we could not have the current

  :-) considering how ugly the xor effect looks it funny that it's (part
of) a reason why the nasty grab X is used by fvwm

> why people want manual placement at all.  I think it is a big

  yes it is but why wouldn't it use opaque window when given window
qualifies for opaque move?

> in fvwm and probably in many other window managers and

  it looks like something in gnome apps is doing it too, after double
click (not sure if it's still a problem but few months ago a double
click in gnome app froze everything (all X programs, I could still
switch to anoth virtual console) for about 10 seconds) - VERY annoying.

	erik

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 2 Dec 2002 17:58:26 +0100

> of) a reason why the nasty grab X is used by fvwm

Well, it is considerably faster too and does not cause any redraws
on below windows.  A non grabbing implementation of wire frame
move is about as slow as opaque moving.

> > Personally I wonder

It's the choice of the user.  And of course wire frame operations
are still common for resizing.

Bye

Dominik ^_^  ^_^

---

From: Tor Stormwall <[email-masked]>
Date: 02 Dec 2002 21:34:30 +0100

> if you run "real-time" updating applications (video, monitors).

Thank you. That worked :)

Best Regards,
Tor Stormwall
----------------------
http://creson.com/~tor

---

From: Ben Winslow <[email-masked]>
Date: Mon, 02 Dec 2002 16:04:25 -0500

>that gives a good contrast.  But we could not have the current
[snip]

>>grabbing the server was not introduced at all?
[snip]

>in fvwm and probably in many other window managers and
I'd love to see an (optional) non-blocking resize--OpaqueMove helps for moves, of course, but it's still very annoying when X calls start blocking because I'm resizing a window. :) 

-- 
Ben

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 3 Dec 2002 00:18:40 +0000

On 02 Dec 2002 16:04:25 -0500, Ben Winslow wrote:
> 
> I'd love to see an (optional) non-blocking resize--OpaqueMove helps for 
> moves, of course, but it's still very annoying when X calls start blocking 
> because I'm resizing a window. :) 

  Style * ResizeOpaque

Regards,
Mikhael.

---

From: Ben Winslow <[email-masked]>
Date: Tue, 03 Dec 2002 14:22:35 -0500

>>because I'm resizing a window. :) 

I meant in addition to this--OpaqueResize causes a *LOT* of redraws for 
the underlying window (although apparently it's not as bad as I 
remember, e.g. mozilla doesn't seem to have a huge problem with it 
despite oldish CPU--p3 500).

Something in the general direction of a non-XOR frame as was being 
discussed would be nice, but perhaps I can live with OpaqueResize--the 
only app that seems to redraw excessively is xterm, and its redraws are 
only annoying, not slow.

-- 
Ben

---

From: Marcus Lundblad <[email-masked]>
Date: Tue, 3 Dec 2002 21:26:25 +0100 (CET)

> only app that seems to redraw excessively is xterm, and its redraws are 
I think the reason for this is because xterm (and other VTs) measure their
geometry in charcells instead of pixels, so the resize gets "choppy".
Am I correct?

//Marcus

---

From: [email-masked]
Date: Tue, 3 Dec 2002 23:35:51 +0100

> geometry in charcells instead of pixels, so the resize gets "choppy".

No.  The problem is that many applications redraw themselves way
too often and delete their contents when doing it.  And the
application would have to know at which side it is grabbed to set
the right bit_gravity.

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