Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!WSL.DEC.COM!haynes From: haynes@WSL.DEC.COM Newsgroups: comp.windows.x Subject: Re: xset m accl. theres. and XNextEvent (MotionNotify) Message-ID: <8806291613.AA11396@gilroy.dec.com> Date: 29 Jun 88 16:13:22 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 61 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. One of the problems many X servers have is that they assign higer priority to servicing outgoing device events than to processing incoming X requests. What happens is that the user moves the mouse, the server sends out a mouse motion event, which causes the application to send a certain number of output requests to the server, and the server can't process all of them before the next mouse motion event. It gradually gets farther and father behind, eventually dieing in some more or less obscure way. Pointer motion hints causes it to do your painting requests before looking for more mouse motion, since it isn't sending out mouse events until it sees your QueryPointer, which will presumably be after all of you painting requests. Another alternative is to sit in a loop doing QueryPointer and processing the current mouse position. This has the advantage that your input side and output side stay synched, but has two disadvantages: 1) it creates a fixed load on the server and your application, even when the mouse isn't moving, and 2) it makes it tricky to handle the other incoming X events (you need to do some sort of simple timesharing and scheduler). Unfortunately doing a QueryPointer loop in a toolkit application is hard. The last alternative is to make your server fast enough, or smart enough, to not "get behind". There are various techniques including scheduling I/O more "fairly", packetizing output, timeslicing, etc. This is what I meant by "fix 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.) Doing a XSync after completing your output requests, but before asking for the next mouse event should work, but would be slow. Pointer motion hints should acheive the same effect with better performance. Doing good mouse tracking is one of the trickier areas of using X. -- Charles P.S. I'm speculating that the obscure server errors you're seeing are a result of input buffer overruns due to being so far behind.