[OSX] Cursor "jumps" at borders of window

[DorpsGek]

rdoger6424 opened the ticket and wrote:

When I play in windowed mode on my mac (OS X 10.6.5), the cursor seems to "jump" when I am close to the left edge of the window, and seems to "stick" when I am on the right edge.
The distance seems to vary proportional to the distance the window is from the left edge of the screen (so this does not happen if the window is all the way to the left side of the screen (for moving into the window horizontally), and/or all the way to the top (for moving in vertically)).
When the window is in the middle of my screen, when I move into the openttd window from the top, my cursor moves to the right as it enters the screen.
I know that I'm not explaining this well enough, so feel free to ask for clarification.

Reported version: 1.1.0-beta2
Operating system: Mac OS X

---

This issue was imported from FlySpray: https://bugs.openttd.org/task/4392

[DorpsGek]

planetmaker wrote:

Does that happen only under certain conditions, like when moving 'into' the window from the all-windows overview? Or always? Did you compile yourself or do you use the one found on our website?

And: how big are these jumps. Is there a relation of the jump to the right wrt the left border of the window to the screen's left border? Same thing with the jump in vertical direction: a relation between the jump length and the upper or window position wrt the screen's upper border?

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment9436

[DorpsGek]

rdoger6424 wrote:

The thing that triggers this is whenever I move the mouse down into the window (i.e. from the top of the screen into the window). If completely refrain from crossing the top window boundary, it works fine, even if I move the window further to the right / bottom. Going into any of the exposé modes, and then back into the window does not trigger the problem.
I downloaded and used the dmg file on the website.
There is a 1:1 relation between the gap between the window and left edge of the screen and the "no-go-zone" on the left edge of the window.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment9437

[DorpsGek]

Rubidium wrote:

Given there was a significant rework of lots of Mac OS X handling of the video backend it might been introduced by that rework. To be sure I'd like to know whether you can reproduce it with the nightly before that rework, and if so whether you can with the nightly after the rework.

So, can you reproduce this issue with the r21546 nightly? You can find it at http://www.openttd.org/en/download-trunk/r21546
If you can't, can you reproduce it with the r21588 nightly? You can find it at http://www.openttd.org/en/download-trunk/r21588

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment9520

[DorpsGek]

Rubidium wrote:

It would be helpful if you could perform the tests I suggested relatively quickly as those nightlies are about to be removed from the binaries server.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment9738

[DorpsGek]

rdoger6424 wrote:

Unfortunately, I can't do the tests, as I am away from my mac and will be for quite some time.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment9739

[DorpsGek]

leecbaker wrote:

I can for sure reproduce this bug on latest trunk (r22893). I'll have a look at this in a day or two- I've recently been looking at the OS X video code in the cocoa/ folder, and suspect there may be an issue with the conversion from screen coordinates to window coordinates.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment10316

[DorpsGek]

rdoger6424 wrote:

It happens on the latest stable as well. I have not tried with lion yet, only with Snow Leopard.

Thank you for reminding me of this bug. I was out of the country for a few months.

Should I update the version or keep it at 1.1.0-beta2?

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment10317

[DorpsGek]

leecbaker wrote:

Steps to reproduce 4392:

* Run OpenTTD (main menu appears)
* Move window position to 100px right of left edge of screen. Put mouse on left edge of screen.
* Move mouse right 150px, so it is 50px within the OTTD window. BUG: cursor is drawn 150px from the window edge (250px from the screen edge), instead of 50px from the window edge.
* Click mouse within window. Mouse cursor will jump to correct position until the cursor is moved outside the window again.

I'm using 10.7, with r22893.

What appears to be going on:
At wnd_quartz.mm:501, locationInWindow is used to convert from window coordinates to view coordinates. When the mouse is moved outside the window, the MouseMoved event quits targeting the OTTD window (and [event window] becomes nil). The window is provided with screen coordinates instead of window coordinates. This is mentioned in the NSEvent locationFromWindow documentation:

"With NSMouseMoved and possibly other events, the receiver can have a nil window (that is, window returns nil). In this case, locationInWindow returns the event location in screen coordinates."

This wouldn't be a problem (the cursor is only needed when the mouse is positioned inside the window), but the mouse moved event doesn't target the window again until it is clicked on.

At this point, my Cocoa-foo isn't strong enough to know how to fix this. From the documentation, I can't figure out how you get to the state where the NSEvent has a nil window. It obviously happens when the mouse leaves the window, and returns when you click inside the window; is this something that OTTD is doing, or is it a Cocoa thing?

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment10318

[DorpsGek]

planetmaker wrote:

Might be related to mode switches (fullscreen, window, (un)hide) where in the first two cases the driver is re-initialized and in the second the focus regained or given away

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment10319

[DorpsGek]

brandonr wrote:

I am able to duplicate this issue using OS X 10.5.8 in the current revision (r23826).

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment10787

[DorpsGek]

soulfairer wrote:

Hi,

I've changed the quartz code for the mouse position. Now it seems to work, both in fullscreen and windowed mode (for fullscreen: pointer position is consistent when menu shows).

My two cents for this marvelous project!

Attachments

• openttd-1.2.3-macos-mouseposition.patch (0.16 KiB)

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment11679

[DorpsGek]

soulfairer wrote:

diff -u for this as pointed out by Michael Lutz!
(please disregard patch 2 - I haven't used diff for years!)

Attachments

• openttd-1.2.3-macos-mouseposition-2.patch (0.44 KiB)
• openttd-1.2.3-macos-mouseposition-3.patch (0.44 KiB)

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment11683

[DorpsGek]

planetmaker wrote:

I'm afraid that this patch doesn't solve the issue for me. On the contrary, it introduces further complications:
- When I move the cursor into the window it disappears under certain conditions.
- The cursor still jumps: use a window for OpenTTD. Drag the window to another place. Move the cursor somewhere else, not into the openttd window. Move back to the openttd window. You see the cursor nicely jumping when entering the window
- Even worse: the cursor disappears also frequently when click anywhere on the title screen. It re-appears when I move the mouse, but I have a very hard time to select anything. It seems that cursor and mouse coordinates differ with this patch by as mutch as the window is offset wrt desktop origin.

As much as I'd like this issue see fixed: I'm afraid that this patch makes the mouse behaviour quite a bit worse for me (OSX 10.6.8).

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment11688

[DorpsGek]

soulfairer wrote:

For me (OSX 10.8) it worked. Can someone test it also in OSX? I don't have access to a 10.6.x machine, will install a VM.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment11714

[DorpsGek]

Matthieu wrote:

I think my patch will solve all the problems. I'm on osx 10.8.2 and some test have to be made on osx < 10.7. Thanks in advance.

Attachments

• fs4392.diff (0.92 KiB)

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment11958

[DorpsGek]

michi_cc wrote:

You do realize that MAC_OS_X_VERSION_MAX_ALLOWED only describes which SDK is used to compile OTTD, right? You probably want IsMacOSVersionAtLeast instead. What happens if convertRectFromScreen is called on e.g. 10.5?

The compile farm builds OpenTTD with the 10.5 SDK and upgrading is difficult as we'd need a new cross-compiler, which means the new code path wouldn't be used anyway. Maybe this could be worked around by fudging with performSelector.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment11965

[DorpsGek]

Matthieu wrote:

Ok, i've read some documentation about weak linking and i think i've understood what do you mean.

Attachments

• fs4392_2.diff (0.99 KiB)

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment11986

[DorpsGek]

michi_cc wrote:

Is it necessary to call convertRectFromScreen on 10.7 or later because e.g. convertScreenToBase doesn't work anymore? If yes, we have a problem because MAC_OS_X_VERSION_MAX_ALLOWED will be MAC_OS_X_VERSION_10_5 on our compile farm. If not (which I think is true, as the docs only say deprecated, not removed), the code is almost good in theory. It's missing some {} around the if statements, see http://wiki.openttd.org/Coding_style# Control_flow

No 10.7 to test available, so I can't say anything about whether it works in reality and fixes the bug. I do believe however that it should be "@selector(convertRectFromScreen:)" (i.e. just one : ).

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment11988

[DorpsGek]

Matthieu wrote:

Hi

I think it's necessary as that's the new way to do things on OSX. That's the coding convention on that platform. See Apple guidelines or look at the informations on http://developer.apple.com/library/mac/# documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/APIs/APIs.html

I think that's not a problem if the project is compiled againts 10.5 sdk.
- There is some other code that depends on 10.7 sdk;
- Later the projects might be built on 10.7 sdk;
- It runs on my osx 10.8.

I added curly brackets for if statements in the joined patch.

What does mean "waiting on reporter" status? I don't speak a very good english and i'm not sure. Does it mean we must wait on the bug creator (Roger F) to test, approve and add to trunk the patch ?

Attachments

• fs4392_3.diff (1.03 KiB)

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment12014

[DorpsGek]

michi_cc wrote:

I think it's necessary as that's the new way to do things on OSX.

With necessary I really meant absolutely necessary, i.e. does convertScreenToBase:fromView: fail on 10.7? I don't care if some Apple docs mark that as obsolete as long as it still works. Our compile farm will not get anything else than the 10.5 SDK in the foreseeable future, so our offical binaries will always use convertScreenToBase: and never convertRectFromScreen:. It's still good to have both ways in the code for those that compile themselves (and in case we ever do get a new cross compiler). The patch itself looks good.

What does mean "waiting on reporter" status?

Ideally we would indeed hear from the original reporter. Often enough this is not possible or feasible, but it would still be nice to get a confirmation from somebody else, especially as past experience with OS X bugs has often shown very different results on different system combinations.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment12019

[DorpsGek]

Matthieu wrote:

Ok, Thanks. Waiting for the reporter.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment12034

[DorpsGek]

michi_cc wrote:

I made a binary with the same setup as our compile farm at http://www.icosahedron.de/openttd/patches/openttd-custom-geeea764dM-OSX.zip, could you test if that solves the problem? Please note that it is completely untested by me.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment12046

[DorpsGek]

Matthieu wrote:

Ok, i tested it on my osx 10.8.2. There was no "jumping" problem using it.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392#comment12051

[DorpsGek]

michi_cc closed the ticket.

Reason for closing: Fixed

In r25658.

---

This comment was imported from FlySpray: https://bugs.openttd.org/task/4392