Subject: Things left to do

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Feb 2001 15:33:36 +0100

Okay, I swallowed the bitter pill and removed all tests from the
to do list that are not strictly necessary.  All things on the bug
list that are unlikely to be reproduced and fixed.  The remaining
items are:

134) Investigate DecWindows ConfigureRequest/Notify race condition.
     [reported by Fabien Viallard on 19-Apr-2000]

We need someone with access to this DecWindows application.  Is
this a VMS issue?  We'll have to skip this if nobody has access
to this application.

171) With virtually any border config, when moving opaqually, the borders of
     all underlying windows flick a lot. There is no any flicking in 2.2.x.
     [reported by Mikhael]

Mikhael?  I never had this problem at all.  May this happen
because the X server does not have BackingStore activated anymore
or because it runs out of memory?

172) Investigate travelling rxvt-2.7.4
     [reported by PDS]

I'll take care of this.

 92) Test session management restart code.

I stripped this item down.  I'd be contend if restarting fvwm does
not lead to unpleasant surprises.

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: Dan Espen <[email-masked]>
Date: Sun, 11 Feb 2001 09:43:43 -0500

> or because it runs out of memory?

It must be something like that.  I use pixmap borders.
On my remote setup, I'm aware of every repaint that takes place.

I can use opaque move on overlapping or underlapping windows
with no flickering at all.  The X server supports backing store.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Mikhael Goikhman <[email-masked]>
Date: Mon, 12 Feb 2001 12:08:15 -0600

On 11 Feb 2001 15:33:36 +0100, Dominik Vogt wrote:
> Mikhael?  I never had this problem at all.

Interesting, I had this flickering in 2.3.x on all machines I worked on.
The default configuration (without rc file) is good enough, then execute:

  OpaqueMoveSize 99
  Style * ResizeOpaque

> May this happen because the X server does not have BackingStore
> activated anymore or because it runs out of memory?

I have several fvwm instalations. It was the same X Server.
I don't run out of memory.

Ok, my XFree86 defaults to -bs. When started it with +bs *and* executed
Style * BackingStore, the mentioned move flickering problem disappeared!

But with both these on, I get more problems. WindowShade is now slower,
and unshading looks bad (unfocussed title and borders while unshading).
More, there is a bug, mini-icon on titlebar is not shown when any
window is first mapped (unfoccussed) and only is shown when focussed.
Also Opaque Resize is slow and flickers not less than without BS.
Menus covering windows popup and popdown slower and so on.

Tested on two XFree86 4.0.1 with different drivers. Also tested with
XFree86 3.3.6. The same results. Just 4.0.x seems to default to -bs
while 3.3.x to +bs. I also played with -wm, no any visual change.

In fvwm-2.2.x borders don't flicker on Expose even with -bs.
This is probably related to rewrittings of the border code in fvwm-2.3.x.
So a more correct description of 171 would be:

171) Without backing store, on expose the window borders flicker a lot
     (with some configs more with some less). There is no any flickering
     of the borders in 2.2.x even without backing store.

     With backing store in X and "Style * BackingStore" (which are not
     default neither in some X's nor in FVWM), there are many problems.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 12 Feb 2001 13:22:22 -0500

Flickering control appears to be a configure option and a BugOpts
option.

I think the stuff in configure (and INSTALL.fvwm) is obsolete.
That appeared to be the case for "--disable-modality".

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 12 Feb 2001 13:38:35 -0600

> Flickering control appears to be a configure option and a BugOpts

I suppose this is not related to the parent message, because AFAIS
FlickeringMoveWorkaround affects client windows not window borders.

> That appeared to be the case for "--disable-modality".

I see that both DISABLE_CONFIGURE_NOTIFY_DURING_MOVE and MODALITY_IS_EVIL
are used in 2 places, so configure and INSTALL.fvwm are up to date.

Am I missing something?

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 12 Feb 2001 14:47:17 -0500

> are used in 2 places, so configure and INSTALL.fvwm are up to date.

Maybe.  Using:

BugOpts ModalityIsEvil

turns on the feature regardless of what you did during
configure.

I don't think either feature is controlled by configure any more.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 12 Feb 2001 15:04:37 -0600

> I don't think either feature is controlled by configure any more.

Actually, the command you give as example restores the configured value.
You may switch it on and off by adding an argument "true", "false" or
"toggle", but the default (no boolean argument) is what you configured.

I can live with either configuring defaults or hardcoding them.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Mon, 12 Feb 2001 16:23:37 -0500

> "toggle", but the default (no boolean argument) is what you configured.

Sorry, you're right.  I see what it does now.