Subject: Re: FVWM: FvwmPager goes crazy?

From: Dan Espen <[email-masked]>
Date: Sat, 22 Feb 2003 16:13:38 -0500

Gert Brinkmann <[email-masked]> writes:
> Dan Espen wrote:
> 
> > Thanks for the description.  It led me right to the problem.
> > It seems to work pretty well for me now.
> > If you have the time, try it out and let us know if you see
> > anything else.
> 
> Today i had the time for testing and yes, the bug is fixed now. The 
> screen does follow the pointer nearly exactly.
> 
> But there are two things left to make it perfect:
> 
> 
> A) When dragging around the screen with mousebutton 3 the screen should 
> be positioned with its _center_ right under the mouse pointer. When 
> moving the mouse pointer out of the pager to the right or bottom window 
> edge, and returning the mouse pointer back into the pager, the screen is 
> moved some pixels to early, so that the mouse pointer is not over the 
> screen, but instead does follow the screen with a lag of some pixels.
> 
> When leaving the pager over the top or left edge, this does not happen. 
> The mouse is still on the screen center then.

OK, I can reproduce this.  I haven't looked for the cause, yet.

> B) I have opened Mozilla with some windows in page 0 of the desktop. 
> Mozilla refreshes its windows *very* slowly and eats up a lot of CPU 
> (this is not an fvwm issue). This leads into a very slow moving screen 
> in the pager, which i can understand, because the CPU is busy. But there 
> could be some things be done better, i think:
> 
> - Mozilla refreshes its windows even if page 0 is not touched by the 
> screen. It would be enough to refresh the _visible_ windows only.

This I don't see.  On a 3x3 desktop, I have mozilla on one
page.  It slows down a little there, but not terribly.
I've got 1.2b.

> - I guess that this is difficult to implement: If the screen is far 
> behind the mouse pointer it should be drawn directly at the current 
> mouse pointer position the next time without drawing the screen at many 
> positions between the current screen and the current mouse pointer 
> position. This will lead to a possibly jumping but much faster movement 
> on slow machines.
> 
> - Maybe this is possible already? It would be a good idea if you could 
> tell fvwm to not refresh all or some windows but only show there 
> windowborder when moving the screen on the pager. (like it can be done 
> on moving or resizing a window)

I think you sent this last response directly to me.
Don't forget to respond to the fvwm list.

-- 
Dan Espen                           E-mail: [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].

---

From: Gert Brinkmann <[email-masked]>
Date: Sun, 23 Feb 2003 14:55:49 +0100

> page.  It slows down a little there, but not terribly.

Well, certainly i am not sure if it is really refreshing, because i 
cannot see it when not currently shown on the screen. But this is the 
only explanation i have why the pagers becomes so very slow. (When 
moving around the mouse pointer a lot (perhaps 3 full cicles over all 
outer pages) it takes about 3 or 5 seconds until the pager has finished 
the screen-moving. In the meantime you can watch the screen moving 
slowly on the former mouse-move-path.

here: on a 3x3 desktop, mozilla 1.3b (did you mean this, or 1.2.1?)

> Don't forget to respond to the fvwm list.

One milisecond after pressing the send-button i recognized that i did 
forget to set the TO-address correct. Wouldn't it be a good idea to 
automatically set the REPLY-TO-field to [email-masked] in the mailinglist?

Gert

---

From: Thomas Glanzmann <[email-masked]>
Date: Sun, 23 Feb 2003 17:12:54 +0100

> automatically set the REPLY-TO-field to [email-masked] in the mailinglist?

Yesterday i thought the same way. But the truth is that this make things worse.
You should instead of this use the Mail-Followup-To: fvwm <[email-masked]>. The
problem with this is that only a few eMail Clients are aware of it. And I think
mozilla isn't one of them. :-( Also have a look at Sven's signature.

	Thomas
-- 
Sven [email-masked] - put the subscription status into header:
use     "lists address"   when you are *not* subscribed -> request    CCs
use "subscribe address"   when you   *are*   subscribed -> request no CCs
-> http://www.math.fu-berlin.de/~guckes/mutt/setup.php3#lists_and_subscribe
--
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: Dan Espen <[email-masked]>
Date: Sun, 23 Feb 2003 16:49:06 -0500

> here: on a 3x3 desktop, mozilla 1.3b (did you mean this, or 1.2.1?)

When I click on help->about, it says 1.2b.

But, the problem isn't Mozilla, or FvwmPager.

When fvwm  executes  a  Scroll  command,  (which  is  what the   pager
generates), it's  sending  ConfigureNotify   to  windows   that aren't
visible.    (When   the  window  becomes    actually  visible  it  gets
VisibilityNotify and Expose.)

I don't think it should be doing the ConfigureNotify.

---

From: [email-masked]
Date: Mon, 24 Feb 2003 00:11:42 +0100

> I don't think it should be doing the ConfigureNotify.

It's required by the ICCCM :-/

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].

---

From: Dan Espen <[email-masked]>
Date: Sun, 23 Feb 2003 19:36:54 -0500

> It's required by the ICCCM :-/

I don't understand.  The window is completely out of sight.
Yet fvwm is sending it ConfigureNotify.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 24 Feb 2003 10:45:15 +0100

> > On Sun, Feb 23, 2003 at 04:49:06PM -0500, Dan Espen wrote:
[snip]
> Yet fvwm is sending it ConfigureNotify.

That does not matter.  Theoretically, the application could still
want to respond to the ConfigureNotify.

Bye

Dominik ^_^  ^_^

---

From: Gert Brinkmann <[email-masked]>
Date: Thu, 27 Feb 2003 15:52:20 +0100

> VisibilityNotify and Expose.)

Just for my understanding: What are the messages "VisibilityNotify" and 
"Expose" good for? Is it a mozilla bug that it reacts on only 
"VisibilityNotify"?

Perhaps this should be configurable as a Style somehow? Then fvwm was 
ICCCM compliant but the user can decide if this makes sense.

Gert

---

From: Dan Espen <[email-masked]>
Date: Thu, 27 Feb 2003 10:30:24 -0500

> "Expose" good for? Is it a mozilla bug that it reacts on only 

Actually, that part of my reply was meant for the other Fvwm
developers.  I was describing the X events an off-screen program
gets on a scroll vs. the on-screen events.

Mozilla most likely repaints itself on all three events,
as it should.

> ICCCM compliant but the user can decide if this makes sense.

I looked in the ICCCM and I don't see the relevant part.
I don't think this qualifies as moving the window.
The window is in virtual space so its not moving in real space.

I think something should be done but I'm not working on a fix
right now.  Maybe someone else will, or I might come back to it.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Feb 2003 16:39:46 +0100

> "Expose" good for? Is it a mozilla bug that it reacts on only 

When an applications was partially or fully hidden and becomes
fully visible, the window gets a "VisibilityUnobscured" message.
If it was at least partially visible and becomes fully obscured,
it gets "VisibilityFullyObscured" and if it was fully visible or
fully obscured and becomes partially visible, it gets a
"VisibilityPartiallyObscured" message.

Especially, no event is sent when some parts of the window were
covered and some were not, and the window is moved so that other
parts are covered.  However, Expose events are generated for the
newly uncovered areas (unless backing store is used).

> ICCCM compliant but the user can decide if this makes sense.

No.  First, fvwm is not involved at all in these events.  Second,
it is totally clear from any X documentation I read that
applications have to redraw in response to Expose events.  An
application using VisibilityNotify in place of Expose is simply
broken.

Bye

Dominik ^_^  ^_^

---

From: Gert Brinkmann <[email-masked]>
Date: Thu, 27 Feb 2003 18:40:29 +0100

Thanks for your explanation, Dominik.

phew... complicated... What does "obscure" mean in window manager 
context? Checking a dictionary did not return sensefull results. So, 
what is the difference between "not (fully) visible" and "(partially) 
obscured"?

All the cases that you did describe are ok to send such an event, but 
none of these cover the situation i did mean: When moving the 
pager-screen around with at everytime completely *not* showing the page 
where mozilla is opened, mozilla should not get such an event, isn't it? 
Only if a mozilla window was not (fully) visible and at one time becomes 
more visible than before, it needs to redraw and so requires such an 
event, as i understand.

But Dan allready said that this might be fixed sometime. It is certainly 
of priority C, IMO. (The only thing is that this 
mouse-button-3-scrolling in the pager did arouse my interest for fvwm, 
because it gave me a totally new feeling of a real huge virtual screen. 
But there are enough other interesting things to be found in fvwm...)

Gert

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 28 Feb 2003 10:13:23 +0100

On Thu, Feb 27, 2003 at 06:40:29PM +0100, Gert Brinkmann wrote:
> context?

Being covered by other windows or outside the screen area so that
not a single pixel can be seen.

> Checking a dictionary did not return sensefull results.

You need a better dictionary :-)

> So, 

Fully visible      = all pixels are displayed
Fully obscured     = no pixel is visible
Partially obscured = some pixels are visible and some are not

> where mozilla is opened, mozilla should not get such an event, isn't it? 

Right.

> more visible than before, it needs to redraw and so requires such an 

Yes.  Expose events inform a window of newly visible areas.

Bye

Dominik ^_^  ^_^