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.Amazingly quick update, thank you so much for considering this addition! You rock! Image may be NSFW.
Clik here to view.Image may be NSFW.
Clik here to view.
I didn't reply immediately because I made further tests to be sure I'm not talking nonsense. I checked the source code and the changes you made, and I can't for the life of me see where's the issue because everything seems correct there. An image is worth a thousand words, so I'll let the test skin below speak for itself (didn't want to release the full technique just yet, but anyway):
Test_1.0.0.rmskinOn left click, the skin captures the part of the screen corresponding to its area to an A.gif file created in the skin folder. The border of the skin will change color from yellow (idle) to red (saving frames using shotcap) to orange (converting frames to gif using gifski), before finally returning back to yellow (idle) when finished.
Now, as explained earlier, I used the same 0.04 seconds interval, but for the 1.2 version of shotcap, and now the animation speed in the resulting GIF is much faster as it should be, basically the opposite of the 1.1 version also included in the package, where the speed was much slower. In fact, to replicate the 'normal' speed, one has to set -repeat 0.004 instead of -repeat 0.04 in the [Command1] measure.
You can test this by playing, say, some YouTube video and capturing a relevant part of it, first with the default 0.04 interval and then with the 0.004 one. Just left click the skin and wait for the border to go yellow > red > orange > yellow before checking the result (if you left click again while it's capturing, the capturing stops, so you can control how much you capture, by the way). By default, I left the Shots variable at 125 like used eariler as an example, but you can adjust the number of frames captured to a different number if needed.
Any idea why that faster speed happens, and whether there might be a solution to make it at least close to what is supposed to be? Image may be NSFW.
Clik here to view.
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!
Statistics: Posted by nstechbytes — Today, 3:27 am
