FPS precision loss when passing integer delay to gm convert (60 FPS is considered same as 50 FPS)

[Hyper Sonic]

I was wondering what the "delay" option meant, and it seems passed to gm convert command as a number of hundredths of s between each frames (see man gm, search delay).

This induces a loss of precision in FPS as compared to GIF frame ms duration as found in editors like Aseprite.

I didn't see differences with naked eye, but when opening in Aseprite, I could see that the standard frame durations were 2 hundredths of second = 20ms <=> 50 FPS instead of ~16ms <=> 60 FPS.

This is about the same difference as playing the Genesis aka Mega Drive PAL version on 50Hz TV where the action and music would actually slow down slightly compared to their 60Hz/FPS counterpart. So while not perceptible for non-trained eye, I can imagine it may be an issue when uploading GIF of time-critical games like fighting games.

I also tested extreme FPS, the max is 79 FPS but in fact, it just sets delay to 0 which in turns sets the true frame duration to 1ms, the only case going below 10ms, which is equivalent to 1000 FPS (of course, my computer couldn't play that so that's just theoretical).

If the limitation of gm convert cannot be overcome, maybe a conversion pass with another tool could at least readjust the frame durations? Either in the middle before we start optimizing frames and packing similar frames together, or at the end if it's not an issue (the operation should be linear so still work after packing same frames together).

EDIT: note that browsers may support up to 50 FPS or even less, so that's something to take into account when making GIF for the web; for it's more something for the user to care about depending on their usage

[Hyper Sonic]

Oops, just realized that GIF's own limitation is 10ms per frame minimum anyway. Aseprite displays ms precision just for visualization in the editor (e.g. before exporting animation in game engine that can do it; or possible .webp but that's although theoretical as browsers may have a hard time showing fast animations like this).

So it's not something that can be fixed by gifine.