SDL_WarpMouse() and SDL_ShowCursor()

David_Olofson · November 25, 2005, 5:46pm

No showstopper - just wondering why it is not documented that
SDL_WarpMouse() has no effect while the mouse cursor is hidden on
some(?) platforms. The logic makes some sense, sort of (why move the
cursor when you can’t see it anyway?), but it helps if things are
documented and concistent across platforms.

While this supposedly doesn’t happen on Win32 (I haven’t verified this
myself), I’ve found some info indicating that this happens on
Solaris, and now I can conclude that it happens on Linux/AMD64 with
Xorg as well. (Guess it’s an X thing, but can’t be arsed to check
right now.)

(“Why would you want to WarpMouse while the cursor is hidden?” you
might wonder. Well, I don’t! I’m using relative mouse data instead of
warping, which is supposedly reliable, and avoids the “can’t move
more than half the width/height of the window per frame” restriction.
I solved my problem here by just swapping the two calls, as all I
needed to do was restore visibility and position of the pointer after
doing some relative manipulation of a scale/ruler widget.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

Christian_Walther · November 28, 2005, 9:51am

David Olofson wrote:

No showstopper - just wondering why it is not documented that
SDL_WarpMouse() has no effect while the mouse cursor is hidden on
some(?) platforms. The logic makes some sense, sort of (why move the
cursor when you can’t see it anyway?), but it helps if things are
documented and concistent across platforms.

While this supposedly doesn’t happen on Win32 (I haven’t verified this
myself), I’ve found some info indicating that this happens on
Solaris, and now I can conclude that it happens on Linux/AMD64 with
Xorg as well. (Guess it’s an X thing, but can’t be arsed to check
right now.)

Here on Mac OS X (Cocoa), SDL_WarpMouse() does affect hidden mouse
cursors (grabbed or not), and that makes perfect sense to me. After all,
even though invisible, the cursor still has a position that is affected
by mouse movements, is reported in mouse events, and can be read using
SDL_GetMouseState() - so one should also be able to set it using
SDL_WarpMouse(). If that’s not the case on X, I’d consider that a bug
(unless the other three properties aren’t satisfied there either).

-Christian

David_Olofson · November 28, 2005, 1:45pm

[…]

Here on Mac OS X (Cocoa), SDL_WarpMouse() does affect hidden mouse
cursors (grabbed or not), and that makes perfect sense to me. After
all, even though invisible, the cursor still has a position that is
affected by mouse movements, is reported in mouse events, and can be
read using SDL_GetMouseState() - so one should also be able to set
it using SDL_WarpMouse(). If that’s not the case on X, I’d consider
that a bug (unless the other three properties aren’t satisfied there
either).

Actually, I’d also consider the X behavior a bug, althogh, if I
stretch (far) I can sort of understand why someone might have thought
it doesn’t make sense to move an invisible pointer.

Either way, this is pretty much irrelevant, as this is apparently the
way some X implementations do it, so we’ll either have to accept that
some SDL applications break on some/most/all X targets, or SDL has to
work around it.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 28 November 2005 10.51, Christian Walther wrote:

Ricardo_Cruz · November 28, 2005, 3:23pm

[…]

Here on Mac OS X (Cocoa), SDL_WarpMouse() does affect hidden mouse
cursors (grabbed or not), and that makes perfect sense to me. After
all, even though invisible, the cursor still has a position that is
affected by mouse movements, is reported in mouse events, and can be
read using SDL_GetMouseState() - so one should also be able to set
it using SDL_WarpMouse(). If that’s not the case on X, I’d consider
that a bug (unless the other three properties aren’t satisfied there
either).

Actually, I’d also consider the X behavior a bug, althogh, if I
stretch (far) I can sort of understand why someone might have thought
it doesn’t make sense to move an invisible pointer.

Making the system mouse cursor invisible and blit some image in its place is
quite a common practice in games. These developers expect the mouse warpping
if they ask to, so, unless it breaks something, I think this should implement
for invisible cursors as well.

Cheers,
RicardoEm Segunda 28 Novembro 2005 13:45, o David Olofson escreveu:

On Monday 28 November 2005 10.51, Christian Walther wrote:

Either way, this is pretty much irrelevant, as this is apparently the
way some X implementations do it, so we’ll either have to accept that
some SDL applications break on some/most/all X targets, or SDL has to
work around it.

//David Olofson - Programmer, Composer, Open Source Advocate

–
Real Time, adj.:
Here and now, as opposed to fake time, which only occurs there
and then.

David_Olofson · November 28, 2005, 4:34pm

[…]

Actually, I’d also consider the X behavior a bug, althogh, if I
stretch (far) I can sort of understand why someone might have
thought it doesn’t make sense to move an invisible pointer.

Making the system mouse cursor invisible and blit some image in its
place is quite a common practice in games.

…but then it’s no longer invisible!

These developers expect
the mouse warpping if they ask to, so, unless it breaks something, I
think this should implement for invisible cursors as well.

Yes, of course. Maybe fixing this does break something; I’m not
sure, BUT…

…unless I’m confusing things, it is actually working as expected
(at least here, on Xorg/Linux), with both hidden cursor and warping.
I get absolutes and deltas, warping works, and I get these "echo"
events caused by the warping, and all is fine.

What happens is that when the cursor is enabled again, it is somehow
moved back to where it was when it was disabled. By enabling the
cursor before doing that final “warp back to the starting point”,
this problem is avoided.

If you’re rendering your own cursor, I think you avoid this problem
entirely, as you won’t be triggering this “enable cursor and on some
targets, move back to where it was disabled” operation.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 28 November 2005 16.23, Ricardo Cruz wrote: