We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 353 - Mouse jumping back and forth in fullscreen vsynced OpenGL
Summary: Mouse jumping back and forth in fullscreen vsynced OpenGL
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 1.2
Hardware: PowerPC Mac OS X 10.4 (PPC)
: P1 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-29 09:46 UTC by Christian Walther
Modified: 2007-06-04 04:23 UTC (History)
0 users

See Also:

Attachments
proposed patch (2.78 KB, patch)
2006-10-29 09:47 UTC, Christian Walther 		Details | Diff
proposed patch (2.78 KB, patch)
2006-10-29 09:47 UTC, Christian Walther 		Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Walther 2006-10-29 09:46:10 UTC 
There's a bug in SDL's Cocoa mouse handling when several mouse moved events have accumulated in the Cocoa event queue at the time QZ_PumpEvents() is called. For some reason, this situation seems to happen only in very specific circumstances, which is presumably why nobody noticed the bug before. Here on 10.4.8 on a PowerBook G4 867MHz, it consistently occurs in my OpenGL application when in fullscreen mode and vertical retrace synchronization is on (SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 1)). It does not happen when I turn off vsync and instead throttle the frame rate to approximately the same value using SDL_Delay().

What the current code does in this situation is:
1. For the first one of the accumulated mouse moved events, the mouse location or delta stored in the event is ignored, instead the current mouse location is queried by calling a global function, and passed to SDL as an absolute location.
2. For all subsequent events, the deltas stored in the events are added up and passed to SDL as a relative movement.

The problem is that the function called in 1. (+[NSEvent mouseLocation]) returns the *current* mouse location, i.e. after all pending events, not the one after the currently processed event. In other words, that location already contains the deltas that are going to be added to it in 2.

The effect is that the SDL mouse location gets ahead of the system mouse location, then, after the next call to SDL_PumpEvents, snaps back to the system mouse location. Because the wrongly added deltas are usually only a few pixels, this appears as a general shakiness in mouse movement.
Comment 1 Christian Walther 2006-10-29 09:47:22 UTC 
Created attachment 177 [details]
proposed patch

Here's a patch that solves the problem by eliminating step 2. Other solutions are conceivable, but this one seemed easiest.
Comment 2 Christian Walther 2006-10-29 09:47:44 UTC 
Created attachment 178 [details]
proposed patch

Here's a patch that solves the problem by eliminating step 2. Other solutions are conceivable, but this one seemed easiest.
Comment 3 Christian Walther 2006-10-29 09:54:14 UTC 
Sorry for the double post. I got an error message when trying to submit the attachment (both times), but now I see that it seems to have worked anyway.

(I stupidly overwrote the error message that I had copied to the clipboard and then closed the browser window, but it was something about "field not found: blabla.isobsolete" or so.)
Comment 4 Ryan C. Gordon 2007-06-02 13:58:58 UTC 
Bumping a bunch of bugs to Priority 1 for consideration for the 1.2.12 release.

--ryan.
Comment 5 Ryan C. Gordon 2007-06-03 01:27:11 UTC 
Comment on attachment 177 [details]
proposed patch

Obsoleting attachment (dupe of Attachment #178 [details]).

--ryan.
Comment 6 Ryan C. Gordon 2007-06-04 04:23:57 UTC 
This is fixed in svn revision #3047 for the 1.2 branch. The 1.3 branch is pretty wildly different in this area, so you might want to check and see that that bug exists in a different form.

Thanks!

--ryan.