Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!bloom-beacon!SRC.DEC.COM!msm
From: msm@SRC.DEC.COM (Mark S. Manasse)
Newsgroups: comp.windows.x
Subject: Re: UWM network use followup
Message-ID: <8903200443.AA21539@jumbo.pa.dec.com>
Date: 20 Mar 89 04:43:00 GMT
References: <890032@hpfcdq.HP.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 43


> If uwm were to wait for MotionNotify events, you would see window move
> and resize operations slow to a crawl.  You'll see the same QueryPointer
> scheme in twm.

How some people will torture other users of shared resources, just 
to improve performance by a sixtieth of a second.... 

"Slowed to a crawl" is quite an overstatement.  The current servers 
give event dispatching high priority, so you get your event just 
about as quickly as you get the response to your QueryPointer; event 
dispatching is more complicated than request processing, but not 
much.  The overhead in Xlib is somewhat higher for events than for 
responses, but we're only talking tens of microseconds.

The real problem is that if you use MotionNotify events you're likely 
to either fall behind the server or have the server fall behind you.  
You must 1) do event compression on the client side, and do some 
synchronizing action periodically in case the painting operations 
you're issuing are too difficult for the server to keep up with, 
or 2) use PointerMotionHint.

Detailed analysis: while the mouse is moving, the server will generate 
an event for you once every screen refresh or so.  If the processing 
time for a motion event takes longer than that, a large queue of events 
will build up behind the window manager.  This will result in feedback 
which is tracking places where the mouse used to be.  By discarding 
all MotionNotify events which are immediately followed by another 
MotionNotify for the same window, you can remedy this.  Unfortunately, 
that's not good enough: the painting operations your window manager 
generates to produce feedback may be very inexpensive, but the server 
processing time to execute them may be large.  Then the event 
compression won't help any: the window manager can keep up with server 
events.  But the queue of painting requests between the window manager 
and the server will grow and grow, causing the same appearance as 
before.  We can solve this by forcing some synchronizing operation 
to take place periodically; XQueryPointer happens to work for that, 
but XSync would work as well.

Using PointerMotionHint solves all the synchronization problems, 
but it does cost you a little in performance.

Mark