Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!purdue!bu-cs!bloom-beacon!oracle!jonnyg
From: jonnyg@oracle (Jon Greenblatt)
Newsgroups: comp.windows.x
Subject: Re: xset m accl. theres. and XNextEvent (MotionNotify)
Message-ID: <8806281848.AA02828@rover.UMD.EDU>
Date: 28 Jun 88 18:48:11 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 37


 >Hi Dan,
 >
 >Sorry about the terseness of my message, I didn't know what degree of
 >expertise to aim the reply at. Here's an amplification.
 >
 >Pointer motion hints is something you can turn on that affects the
 >delivery of mouse motion events. What setting it does is tell the
 >server to send you one mouse motion event (the "hint") any time the
 >mouse moves, but after sending that one mouse motion event, it will
 >wait for an ack from you before sending any more. You send the ack by
 >doing a QueryPointer or by doing an AllowEvents (?) which causes the
 >server to go back to the state where it's looking at mouse motion and
 >ready to send you a hint. This lets you use an event driven model for
 >the program, but still synchronize with the server.
 
 ...
 
 >Mouse compression is a client side technique, only useful if your
 >*client* is falling behind in processing incoming mouse events. It's
 >what Xlib did in X10, when you get an incoming mouse event, you peek at
 >the event queue to see if the next event is a mouse motion event for
 >the same window. If it is you throw away the current one and iterate.
 >The toolkit uses this technique when a widget asks for "mouse
 >compression". It turns out to not be as useful as you might imagine,
 >since most applications can actually process mouse motion fairly
 >quickly (as you've discovered.)
 
 ...
 
 	Huh, it seems to me the server does mouse compression for you.
 Having the client do it is stupid. Every windowing system I have used
 does this by default, read the manual carefuly.
 
 						JonnyG.