[PR #1409] Parallelize capture saving to disk for ImageCapture #1359

New issue

Open

opened 2026-02-26 09:34:33 +03:00 by kerem · 0 comments

kerem commented

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

Owner

📋 Pull Request Information

Original PR: https://github.com/NickeManarin/ScreenToGif/pull/1409
Author: @Wouterdek
Created: 8/24/2025
Status: 🔄 Open

Base: master ← Head: feature/parallel-saving

📝 Commits (1)

8644c84 Parallelize capture saving to disk for ImageCapture

📊 Changes

3 files changed (+74 additions, -16 deletions)

View changed files

📝 ScreenToGif/Capture/BaseCapture.cs (+46 -14)
📝 ScreenToGif/Capture/DirectImageCapture.cs (+14 -1)
📝 ScreenToGif/Capture/ImageCapture.cs (+14 -1)

📄 Description

This PR adds additional capture consumer tasks, which are hinted to run in parallel. These tasks speed up the encoding and saving process, which was previously a bottleneck causing large memory usage and long waiting times at the end of recording. The degree of parallelization is set conservatively to avoid overwhelming the CPU on weaker systems. It is currently hardcoded at 25% of cpu cores (16 cores => 4 tasks, 12 cores => 3 tasks, 8 cores => 2 tasks, <8 cores => 1 task, ...)
This change is implemented for ImageCapture and DirectImageCapture, other capture methods are unchanged.

Performance

Before this change, recording 2 minutes of 1080p 60hz would spike my RAM usage up to 30GB and take over a minute of "Stopping..." before proceeding to the editor.
After this change, I can record 4k 60hz with RAM usage below 800MB and the editor immediately opens after stopping recording.

Safety

Capture() and Save() already run async with a blocking collection, which made it easier to implement this change. However, when saving multiple frames in parallel, multiple frames may try to append to Project.Frames at the same time. I've put a lock around that line to avoid race conditions corrupting the list. Also, a later frame may finish before an earlier one, so frames may be saved out of order. Therefore, I've added a post-process sorting step to ensure a correct order of Project.Frames.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/NickeManarin/ScreenToGif/pull/1409 **Author:** [@Wouterdek](https://github.com/Wouterdek) **Created:** 8/24/2025 **Status:** 🔄 Open **Base:** `master` ← **Head:** `feature/parallel-saving` --- ### 📝 Commits (1) - [`8644c84`](https://github.com/NickeManarin/ScreenToGif/commit/8644c849d6df96138fd9a7bcc4afc15881db724a) Parallelize capture saving to disk for ImageCapture ### 📊 Changes **3 files changed** (+74 additions, -16 deletions) <details> <summary>View changed files</summary> 📝 `ScreenToGif/Capture/BaseCapture.cs` (+46 -14) 📝 `ScreenToGif/Capture/DirectImageCapture.cs` (+14 -1) 📝 `ScreenToGif/Capture/ImageCapture.cs` (+14 -1) </details> ### 📄 Description This PR adds additional capture consumer tasks, which are hinted to run in parallel. These tasks speed up the encoding and saving process, which was previously a bottleneck causing large memory usage and long waiting times at the end of recording. The degree of parallelization is set conservatively to avoid overwhelming the CPU on weaker systems. It is currently hardcoded at 25% of cpu cores (16 cores => 4 tasks, 12 cores => 3 tasks, 8 cores => 2 tasks, <8 cores => 1 task, ...) This change is implemented for _ImageCapture_ and _DirectImageCapture_, other capture methods are unchanged. ### Performance Before this change, recording 2 minutes of 1080p 60hz would spike my RAM usage up to 30GB and take over a minute of "Stopping..." before proceeding to the editor. After this change, I can record 4k 60hz with RAM usage below 800MB and the editor immediately opens after stopping recording. ### Safety `Capture()` and `Save()` already run async with a blocking collection, which made it easier to implement this change. However, when saving multiple frames in parallel, multiple frames may try to append to `Project.Frames` at the same time. I've put a lock around that line to avoid race conditions corrupting the list. Also, a later frame may finish before an earlier one, so frames may be saved out of order. Therefore, I've added a post-process sorting step to ensure a correct order of `Project.Frames`. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem added the

pull-request

label

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

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#1359

No description provided.

Rows
Columns