Add FPS compatible option in second mode of the animation editor snapping

[TokageItLab]

• Fixes Animation editor key snapping is rounded to some predetermined value instead of using exact snap value #98609
• Supersedes Fix animation editor snapping value not lowering as intended when holding shift #98826 Now conflict is solved

Makes it optional to snap the FPS to a close integer FPS when in SecondMode.

Partially revert #97569 to disallow fractional FPS because KeyEditor's spin slider syncs with the FPS of the Snap setting, but KeyEditor's spin slider only allows integers, so if fractional FPS is used for snapping, KeyEditor's spin slider will break. Moreover, it is not consistent with this FPS compatible option.

Even if the KeyEditor spin slider allows fractional values, this will still cause problems due to lack of precision¹, so the fundamental solution is to separate the FPS values for KeyEditor/Timeline from the step(snapping) values. In other words, it means that we need to add a FPS value as well as a step value to the Animation property, but I feel that it should be an editor-only property because it is too specific to the niche case of fractional FPS.

Footnotes

1. Since the value of time in KeyEditor exceeds 10.0 usually, there is a lack of precision if we want to use a step of 0.0625 since it will be like 10.0625 or 100.0625 ↩

[SaracenOne]

Reviewed at animation meeting 👍

[Repiteo]

Thanks!

[Macksaur]

Hello, can you explain/document this line better? It's causing the animation player to unselect keyframes when I click them in my fork. What is this line trying to solve? Thanks!

[TokageItLab]

The FPS in the key edit inspector is displayed dependent on the FPS of the snap value. For example, a key placed at 1s will appear as follows in FPS mode:

I thought that changing the FPS with the keyedit inspector displayed would implicitly change the FPS in the inspector and have some negative effect, but sorry I did not realize that _update_snap_unit() is fired each key time is changed in the inspector (although I think it's a redundant).

There are some instability issues, such as undo after switching from second mode and keys not working due to spin box arrows, but this seems to be a problem that has been occurring for some time and probably needs to be revert in this area and stabilized from other parts.

[Macksaur]

Ahh, thank you for these details! This is starting to make sense. Hopefully these redundant method calls can be untangled easily. For now I will remove this line and deal with any eccentricities on my end. Cheers!