Howdy,
Just tried the most recent CVS. I found that the patch from 6/25 to
windows/x11drv/event.c has led to mildly annoying mouse behavior in
certain (admittedly very limited) cases. Here is the change that did it:
@@ -292,21 +291,8 @@
case ButtonRelease:
EVENT_ButtonRelease( hWnd, (XButtonEvent*)event );
break;
case MotionNotify:
- /* Wine between two fast machines across the overloaded campus
- ethernet gets very boged down in MotionEvents. The following
- simply finds the last motion event in the queue and drops
- the rest. On a good link events are servered before they build
- up so this doesn't take place. On a slow link this may cause
- problems if the event order is important. I'm not yet seen
- of any problems. Jon 7/6/96.
- */
- if ((current_input_type == X11DRV_INPUT_ABSOLUTE) &&
- (in_transition == FALSE))
- /* Only cumulate events if in absolute mode */
- while (TSXCheckTypedWindowEvent(display,((XAnyEvent
*)event)->;window,
- MotionNotify, event));
EVENT_MotionNotify( hWnd, (XMotionEvent*)event );
break;
I assume some problem led to its removal. I regularly try out Myst (the
32 bit version) as a test, running locally on a 700MHz Athlon, so this
can't be blamed on a slow ethernet connection or slow machine. When
dragging the slide controls in the "planetarium", they used to follow
the mouse just fine. With this patch, if you grab the control, move the
mouse and release it, the control does not keep up with the mouse but
just moves at a moderately slow pace until it reaches the point where
the mouse was released (a few seconds to travel from one end to the
other). At that point everything returns to normal.
Other similar slide controls, such as the musical slide controls in the
space ship, work fine with the patch, however. Perhaps it is possible
that the code above was masking some other problem causing the control
to move too slowly to follow the mouse?
Duane