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.