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 2655 - OSX: Window position and global mouse coord spaces are different
Summary: OSX: Window position and global mouse coord spaces are different
Status: RESOLVED ABANDONED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: don't know
Hardware: All Mac OS X (All)
: P2 critical
Assignee: Jørgen Tjernø
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-18 20:50 UTC by Tim McDaniel
Modified: 2018-08-06 21:20 UTC (History)
3 users (show)

See Also:

Attachments
Patch (4.25 KB, patch)
2014-08-08 17:21 UTC, Tim McDaniel 		Details | Diff
Removed ASL_SDL macro switches (4.82 KB, patch)
2014-08-09 19:48 UTC, Robotic-Brain 		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 Tim McDaniel 2014-07-18 20:50:18 UTC 
On OSX, with revision 8729, the coordinate space for window position and the coordinate space for global mouse position don't match.  For a non-fullscreen window, the window position is global relative to the bottom of the menubar.  The global mouse position is relative to the top of the screen.  This affects Cocoa_WarpMouse and potentially other things as well.  Further, the coordinate system for window position is now affected by what screen it is on.  For example, if I have two equal size screens oriented side by side such that the tops of the screens are equal in global space, with the menubar on one screen, and a window straddles the two screens, the window's y position makes no sense.  The window's y position depends on what screen "most" of the window is on.  So if I move the window horizontally just a bit, the y position of my window is now different by the size of the menubar, even though the window was not moved vertically.
Comment 1 Tim McDaniel 2014-07-24 18:35:10 UTC 
I'd like to reiterate that this was a fairly fundamental change (and a breaking change for us).  If SDL OSX is to really support multi-display configurations, this is especially problematic.

If the real concern is preventing windows from going under the menubar, then perhaps a solution involving something like overriding [NSWindow constrainFrameRect] would be less problematic than redefining the global window coord space for the main display.

I recommend reverting SDL_cocoawindow.m revisions 8801, 8739, 8729.
Comment 2 Tim McDaniel 2014-08-08 17:21:49 UTC 
Created attachment 1808 [details]
Patch

This patch essentially reverts the Cocoa window position coord space to be relative to the top of the main screen.  Also fixes a few other Cocoa mouse issues.  Note that the ASL_SDL macro is simply a macro we define when building our SDL lib, used to mark our changes to the SDL code.
Comment 3 Robotic-Brain 2014-08-09 19:48:24 UTC 
Created attachment 1810 [details]
Removed ASL_SDL macro switches
Comment 4 Sam Lantinga 2014-08-17 21:59:33 UTC 
Good point. Your patches are applied:
https://hg.libsdl.org/SDL/rev/c5e33f9a0d03

I'm assigning this bug to Jorgen so he can look at [NSWindow constrainFrameRect] and see if that achieves his goals.
Comment 5 Ryan C. Gordon 2015-02-19 02:45:05 UTC 
(In reply to Sam Lantinga from comment #4)
> I'm assigning this bug to Jorgen so he can look at [NSWindow
> constrainFrameRect] and see if that achieves his goals.

Ping; is there anything we need to do here still, Jorgen? We're triaging for 2.0.4 right now.

--ryan.
Comment 6 Jørgen Tjernø 2015-02-27 00:57:00 UTC 
Good question -- not sure when I'll have a chance to look. Mouse coordinates on Mac have always been a PITA in SDL.
Comment 7 Ryan C. Gordon 2018-08-06 21:20:24 UTC 
Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.