Sure, I'm OK with the general system's overhead and slight imprecission when measuring time, that's not the problem - I can live with the output lasting a few ms longer or shorter than the input interval.I’ve looked into the changes and the issue is indeed related to how the interval is processed. Previously, when the delay was stored as an integer, the system’s overhead and the imprecision in the delay implementation inadvertently produced a longer gap between frames. With the update to use a floating-point value, you now get what you intended—a 40 ms delay between each capture. However, this faster capture rate then results in a GIF that plays much faster because it has many more frames captured per second.
Increasing the repeat interval value (for example, using 0.004 seconds) can bring back the ‘normal’ animation speed. I’m happy to explore further adjustments if needed!
My point was that if I capture frames every 40 ms in the input phase, and merge them back in the output at the same rate (25 FPS means a frame every 40 ms as well), then the output speed in the GIF should be similar to the input speed in the scene where I captured the PNGs from, which doesn't happen. I have to set the repeat interval value to 0.004 aka every 4 ms, in order to replicate a speed of every 40 ms in the GIF output.
This is what I don't understand, as the math doesn't seem to check out. But then, maybe the app needs that 36 ms difference to get the bitmap, save it to file and so on, basically the time cost of doing the job for a single PNG frame. In other words, the user should plan to capture faster than the desired frame rate, to give the app the time to capture at the desired rate, that's the only thing I can think of that would explain the need of a more frequent capture interval than the expected speed in the output...
Statistics: Posted by Yincognito — Today, 6:16 am