replace hint-based relative speed/system mouse scale with a callback-based api

[expikr]

This proposal suggests the following:

• remove SDL_MOUSE_RELATIVE_SYSTEM_SCALE
• remove SDL_MOUSE_RELATIVE_SPEED_SCALE
• add interface SDL_SetRelativeMouseTransform for specifying a custom transform function, or NULL for no modification
• add interface SDL_GetSystemMouseTransform for retrieving SDL's impl of the platform transform function, if it exists.

Rationale:

• Hints can be set from environment variables by the user. This creates two problems
  • The developer may be unaware of the possibility that users may change the behavior unless they specifically override the hint, which would require them to be aware of the possibility in the first place
  • The consumer may be overwhelmed by and paranoid of setting every irrelevant environment hints to exclude unwanted behavior from being inadvertently set by misbehaving programs
• The hint was intended to be entirely developer-facing to begin with. Following the principle of least surprise, it should be such that it should only become relevant to their consideration if they are specifically trying to alter default behavior, instead of needing to be defensive.
• The developer may be unsatisfied with SDL's choice of implementation for the transformation behavior

For the above reasons, it makes much more sense to have these transform behavior be made available and customizable as a callback interface, rather than being locked into a few specific knobs that satisfies no one.

For SDL-implemented platform-specific transforms, SDL can provide an interface that returns a pointer to the function, which the developer can then supply to the callback interface, or employ it directly in their own code outside of the intended callback.

The function prototype of the callback should optionally accept an opaque pointer to any stateful configuration data to be associated with the callback, such as residual tracking or smoothing history. User-defined function can choose not to bother with this pointer, but the SDL-implemented system transform should use it for its stateful data so that users may be able to supply their own state when using it outside of the callback system.

[slouken]

This seems like a good idea to me, however the hint should probably be respected by default, to provide ABI compatibility with existing applications. @icculus, thoughts?

[expikr]

Are hints considered a part of the ABI?

[slouken]

Are hints considered a part of the ABI?

Yes

[expikr]

Considering that system scaling is only implemented for Windows, and that its implementation has been completely broken so far, it’s unlikely that anyone has coded against the hint at this point. If ever there is a time for an excusable ABI break on an inconsequential, unused, and broken hint it would be now, IMO.

Similarly for relative speed scale, its fault lies in being user-alterable by default, so even if a developer has already coded against the hint, it would probably still be justified to break it now while it’s still early.

I just think it’s a really, really bad idea to leave this user-alterable foot gun open by default requiring the developer to be aware of the foot gun in order to close it. It serves no purpose other than creating extra holes that devs need to patch out.

Replacing it with a callback interface solves this issue of being yet-another-paranoid-cs-player-cargo-cult-config-option to obsess over while still permitting developers to have the functionality without worrying that end users will screw it up.

[slouken]

Agreed. I would be okay with removing these hints at this point.

[expikr]

Should I wait for the aforementioned PR to be vetted before working on this as its follow-up so that each change is self-contained, or would it be preferred that the non-breaking fix and the breaking rework be combined as one atomic PR to minimize cluttering the commits?

[slouken]

Let's do this in steps. I'm coming around to your way of thinking about relative mouse mode too, having it not affect mouse position, so let me play with that before you go wild with this.

[slouken]

At this point, given our other discussion and how close we are to release, let's go ahead and close this issue.