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.