Created attachment 775 [details]
Code plus binaries for above test case

Attaching binaries for the test case, with 1.2.14 and pre-release 1.2.15 frameworks.

I forgot to mention -- in the pre-release, if you grab input (Ctrl-G) and hide the cursor (mouse click), then mouse events will come in normally, even in a tight loop. The test app prints messages to stdout when it detects movement.

Created attachment 776 [details]
Alternative method for avoiding cursor freeze

I discovered the source of the problem. In QZ_PrivateWarpCursor, there's a call to turn off Cocoa's default suppression of events for a short interval after posting. In the pre-release, this was rewritten to avoid a deprecated API; however, the re-write doesn't work. It creates a new event source and changes its settings, but that has no effect on my system. Since the created source isn't actually used anywhere, the result is not surprising.

The deprecated call still works, but I found an alternate method that avoids the delay. By disassociating the mouse and cursor position during the warp, the event suppression doesn't kick in. I can't find any documentation guaranteeing that this will work better, but it gets the job done here with non-deprecated calls.

So far, this fix has only been tested on an x86_64 machine running 10.7. The relevant APIs have been present since 10.0, so I hope the behavior is consistent on older machines.

Created attachment 777 [details]
Slightly better version of alternative method


Here's a slightly updated version...we use that API call with mouse grabbing elsewhere, so we need to make sure we don't trample state. Can you confirm this still works for you? If we're good, I'll push the change into revision control.

Thanks!

--ryan.

The current callers kept the state consistent, but better safe than sorry. I tested your version on 64-bit Lion, 32-bit Snow Leopard, and 32-bit Leopard. Mouse control behaved as expected in all three cases. Thanks!

I tried the patch as well and it actually corrects the reported mouse problems in Hedgewars.


What I see now as a minor glitch, is that if you you move the mouse way beyond the sdl window borders, the cursor, if hidden, will begin to flash and become visible until focus is lost and gained again.

This reproducible in the test code and the patched SDL framework in this way: when the app is launched the mouse is visible, press a button and it will become invisible, move it quickly past the window borders a few times and the mouse becomes visible again; press a mouse button again and it will remain visible (most likely it internally sets the visible flag), press a button another time and it will become invisible again.

Created attachment 778 [details]
testwm with the patched 1.2.15 frameworks

> What I see now as a minor glitch, is that if you you move the mouse way beyond
> the sdl window borders, the cursor, if hidden, will begin to flash and become
> visible until focus is lost and gained again.

I don't think this is different than 1.2.14 behavior, or expected behavior in Cocoa. The cursor settings, including visibility, are determined by the window under the cursor: when you leave the SDL window and hit the desktop, you'll see the cursor visible on the desktop. This behavior can be useful sometimes -- in Aleph One's keyboard-only mode, we hide the cursor, but it's possible to move it outside the window and then click to a different app.

The test app causes flicker, because it's bringing the mouse back inside the window on a regular basis. There, you have plenty of time (200 ms) to leave the window, but in Aleph One's mouse mode and I assume in Hedgewars, you'd be polling the mouse too frequently for this to be an issue. And of course, there's always SDL_WMGrabInput, when you absolutely need to hang onto that mouse pointer.

Sorry, I misunderstood. I see the glitch now; it's not hiding the cursor again when it re-enters the window. Playing with the test case, I see 1.2.14 had a small issue in that regard, but it fixed itself when the mouse was moved again.

My patch is now in revision control, hg changeset 6f013dd0add1. I think we're good to go now, so I'm marking this bug Resolved.

--ryan.

The new fix is not really working well. It works only if you continuously pull SDL events in your main loop. I am working on an application (Cube 2: Sauerbraten) which warps the mouse every frame, and has fps limit in menus, and the mouse on mac, with sdl 12.15, is laggy. A workaround is to disable vertical synch, so the main loop runs as fast as it can, but this should be resolved in a better way, and also, it is basically a regression from 12.14, which works fine in a setup of various users (with Mac OSX versions in the range 10.6 - 10.8).

Hello, and sorry if you're getting several copies of this message by email, since we are closing many bugs at once here.

We have decided to mark all SDL 1.2-related bugs as RESOLVED ENDOFLIFE, as we don't intend to work on SDL 1.2 any further, but didn't want to mark a large quantity of bugs as RESOLVED WONTFIX, to clearly show what was left unattended to and make it easily searchable.

Our current focus is on SDL 2.0.

If you are still having problems with an ENDOFLIFE bug, your absolute best option is to move your program to SDL2, as it will likely fix the problem by default, and give you access to modern platforms and tons of super-cool new features.

Failing that, we _will_ accept small patches to fix these issues, and put them in revision control, although we do not intend to do any further official 1.2 releases.

Failing that, please feel free to contact me directly by email (icculus@icculus.org) and we'll try to find some way to help you out of your situation.

Thank you,
--ryan.