Subject: Re: FvwmIconMan Patch - Background/NotifyMotion

From: Dominik Vogt <[email-masked]>
Date: Mon, 3 Jun 2002 19:01:21 +0200

On Fri, May 31, 2002 at 09:03:41PM -0500, Dave Trollope wrote:
> Hi Dominik,
> 
> My original email said "between 1.4.5 and now an if was changed in..." which did as you
> assumed correctly mean 2.4.5 and now. I mean it worked ok in 2.4.5 but didn't work now.

Ah, I see.

> I intend to start looking at the processing of the NotifyMotion events because I think
> we can find some inprovement in handling that event since it is received by apps
> registered for it much more than any event. I noticed that it is in the main switch for
> FvwmIconMan. I'm trying to measure right now the gain by having an if trap this event
> prior to entering the switch(). switch() is slower when 1 case is called significantly
> more times than any other case. What do you think?

(You should rather create a new mail thread for new topics - I
almost overlooked this one.)

I've never compared switch and if, so I don't know if it makes any
noticable difference.  But anyway, FvwmIconMan only requests
Motion Notify events when a button is held down.  This only occurs
if the user presses a button inside FvwmIconMan and then drags the
mouse.  Since FvwmIconMan is the active application at that
moment, it's not *that* bad.

X has already built in a method to reduce the number of
MotionNotify events.  If a window selects "PointerMotionHintMask"
in its event mask, MotionNotify events are sent only when

 - a key button is pressed or released
 - the pointer leaves the window
 - XQueryPointer() is called
 - XGetMotionEvents() is called

FvwmIconMan would benefit from this.  I haven't tried to bind
actions to a motion context though.

BTW, the MotionNotify events that fvwm receives itself if it's
compiled with stroke support are *much* worse.  It might be a good
idea to augment MotionNotify reporting with PointerMotionHintMask
too.  This has to be disabled while a window is moved or resized,
a complex function is running or a stroke is recoring, though.

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: Dominik Vogt <[email-masked]>
Date: Mon, 3 Jun 2002 21:13:15 +0200

> moment, it's not *that* bad.

I have to take that back.  Actually, FvwmIconMan requests all
motion events to be reported, not just when a button is pressed.
I looked in the wrong place.

Bye

Dominik ^_^  ^_^

---

From: Dave Trollope <[email-masked]>
Date: Mon, 03 Jun 2002 22:19:55 -0500

Hi  Dominik.

> > almost overlooked this one.)

Just making sure you are still awake ;-)

> I looked in the wrong place.

Yep, when I was examining the events flying around for the background redrawing I noticed this
flew significantly more than anything else.

I will try to put together some quantitive analysis of switch/if. It will of course depend on
the compiler and optimiser settings so I will try to factor that in. In general,  there is
little a compiler can do to detect that one case is executed more than the rest. The only way
to minimise the impact without code modification is to use a binary tree search, and it is a
minimisation effort. Code modifications can be accomplised by design, filtering them out before
the switch, or ordering the case statements in order of importance - both depend on compiler
implementation. There is simply no way in the language to define one case as more important as
another.

I will write something up for this. As with safemalloc, optimisation is probably only worth it
in focused areas.

Cheers
Dave