Previous thread touching on issues related to this: Animated GIF export rounding frame durations - #3 by Treadlight
Github issue for this: Specify frame delays by frame count · Issue #496 · aseprite/aseprite · GitHub
Some questions. These aren’t meant to poke holes in your idea (which is a good one!), but to get some details necessary to even begin thinking about an implementation, as it isn’t as trivial a change as it sounds.
Where would you expect this to be input? Per-frame like durations are, just as an alternative input method to ms? At the start of the document, with all the durations set to the ms equivalent, and working in ms from that point on?
How should framerates that don’t translate cleanly to durations be stored? Durations in Aseprite are stored as integer ms values. Most common framerates do not have integer equivalents (e.g. 30fps is 33.333… ms), so if the FPS is ever converted to ms durations under the hood, the timing of the whole animation will be off quite quickly. To deal with this accurately, Aseprite would need to either change how it deals with durations, or keep track of your desired fps and introduce leap frames to keep the durations on track. But if it does that, then how should this play along with the ability to change durations per-frame?
FWIW, FPS is usually used by timeline-based animation software, while frame-based software like Aseprite use durations, since that makes more sense for that approach. I feel like if this is added, it should be done with the possibility of a future timeline-based UI in mind, with FPS given first-class status in how it’s stored in memory and in .ase files, rather than simply translating things to ms upon input.