RE: [XonX-Users] Tracking Mouse Movement

[Torrey L. <to...@mr...>]

At 4:04 AM +0100 9/28/02, a.umpleby wrote:
>Hi Chris, Torrey,
>
>>>>mouse motion events are not being picked up.
>>>>...
>>>>xev is telling me that MotionNotify events are being sent.
>>>>...
>>>>xev is reporting MotionNotify events.
>>>
>>>Strangely, running the exact same application under Oroborus for OS
>>>X everything works without a hitch! All my updates and tracking get
>>>handled and graphics update correctly...
>>
>>One difference is that XDarwin does not track any mouse movement
>>except when it is the foreground application (ie. when XDarwin is the
>>application name listed in the menu bar). OroborOSX tracks all the
>>time.
>>...
>>Does your mouse tracker work when XDarwin is the front application?
>
>Judging from what Chris said above (that xev is reporting the motion
>events) I suspect this is not the problem.
>
>I did have a very similar-sounding discussion with one of the Mathworks
>guys who was porting Matlab to OSX - he seemed to be saying that the
>motion events were not getting through, despite xev showing there
>was something happening.
>
>Don't know what happened in the end, though, so it's not very helpful...
>
>Maybe it's worth looking at the source for xev to see what event masks
>it uses and how it sets up the handlers, etc?

Interesting. It would be interesting to see what is different if 
XDarwin is behaving in a non standard way when it is the front most 
application.

>  >Mouse tracking is expensive and generally not advisable unless
>>really needed.
>
>Well, sort of, but it's certainly not the most pressing issue... the biggest
>performance penalty is actually from the two polling event loops (one
>for X11 events, one for Mac events) in OroborOSX. Since it does this
>polling anyway, it's no big deal to pick up the cursor position as it goes
>through.
>
>OroborOSX only intructs the modified XDarwin to create a motion event
>if it notices the cursor has actually moved, so the only real penalty is if
>the cursor is actually moving (and even then it does not seem to be
>as significant as checking the X11 event queue every time it goes
>through its double event loop...)

Yes, polling is bad. Standard XDarwin is bad about this but not as 
bad as it might appear at first glance. I assume some of your 
comments above are about OroborOSX-XDarwin. Standard XDarwin does not 
poll for events in the Mac event loop. In the X server's internal 
event loop it does needlessly poll for events, but only after 
"something happens". Ie. if no X client makes any requests and no HID 
events are received, the X event loop just sits tight and blocks. The 
problem which I've recently become more aware of is that when an X 
client makes a request, the X server thread spends and inordinate 
amount of time checking for events. I've been working on a fairly 
major rewrite of the event path in XDarwin  which should fix this and 
bug #489150, "XWarpPointer only partially works".

--Torrey