[GH-ISSUE #211] [feature request] cache for saving with different frame speeds #172

New issue

Open

opened 2026-02-26 08:45:36 +03:00 by kerem · 1 comment

kerem commented

2026-02-26 08:45:36 +03:00

Owner

Originally created by @JohannesMP on GitHub (Nov 22, 2017).
Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/211

Originally assigned to: @NickeManarin on GitHub.

If you save a gif, where it is analyzed for changes between frames and then saved to a file, that information could be preserved to make saving the gif much faster if all the user does is change frame times.

For example, if you save a gif with frame timings of 50 ms, but realize that that is too slow, overriding frame times to 30 ms would not change the individual frame-to-frame compression that has to occur when saving. Even modifying individual frames, such as extending a frame in case where it contains text that otherwise would disappear too quickly to be readable, would not change the frame-to-frame compression.

It should be possible to cache the compression data after saving the gif the first time, and use that on subsequent saves. Changes like overriding or decreasing frame times would not invalidate the cache, but reversing, transitions, etc. would.

This would vastly speed up workflows where all that a user does is change frametimes.

Since such a cache would take up additional system memory, this could be an option in the save dialogue or settings, so that users that don't often modify frame times as part of their workflow don't have additional memory usage for something they don't benefit from.

Originally created by @JohannesMP on GitHub (Nov 22, 2017). Original GitHub issue: https://github.com/NickeManarin/ScreenToGif/issues/211 Originally assigned to: @NickeManarin on GitHub. If you save a gif, where it is analyzed for changes between frames and then saved to a file, that information could be preserved to make saving the gif much faster if all the user does is change frame times. For example, if you save a gif with frame timings of 50 ms, but realize that that is too slow, overriding frame times to 30 ms would not change the individual frame-to-frame compression that has to occur when saving. Even modifying individual frames, such as extending a frame in case where it contains text that otherwise would disappear too quickly to be readable, would not change the frame-to-frame compression. It should be possible to cache the compression data after saving the gif the first time, and use that on subsequent saves. Changes like overriding or decreasing frame times would not invalidate the cache, but reversing, transitions, etc. would. This would vastly speed up workflows where all that a user does is change frametimes. Since such a cache would take up additional system memory, this could be an option in the save dialogue or settings, so that users that don't often modify frame times as part of their workflow don't have additional memory usage for something they don't benefit from.

kerem added the

🔷Enhancement

label

2026-02-26 08:45:36 +03:00

kerem commented

2026-02-26 09:30:25 +03:00

Author

Owner

@NickeManarin commented on GitHub (Nov 23, 2017):

Alright. :)

Just to add some details of how it works right now:

The frames are only analyzed if the option Detect unchanged pixels is enabled. (So, if you disable this option right now, you can speed up your framerate tests)
The frames are cut (if they retain the same pixels of the previous frame) and saved into a new file inside a temp folder.
This temporary folder gets deleted after the encoding, so the analyzed frames are lost.

@NickeManarin commented on GitHub (Nov 23, 2017): Alright. :) Just to add some details of how it works right now: - The frames are only analyzed if the option **Detect unchanged pixels** is enabled. _(So, if you disable this option right now, you can speed up your framerate tests)_ - The frames are cut (if they retain the same pixels of the previous frame) and saved into a new file inside a temp folder. - This temporary folder gets deleted after the encoding, so the analyzed frames are lost.

kerem referenced this issue

2026-02-26 09:33:34 +03:00

[PR #172] [MERGED] Update Italian translations #1077

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/ScreenToGif#172

No description provided.

Rows
Columns