Refuse loads and renders that would not fit in memory

Opening a project of ninety 17 MP photos got Effector killed by the
kernel's OOM killer: 4.6 GB of decoded RGB on a machine with 3.6 GB free,
and no core dump to show for it. Bulk allocations are now sized first and
refused with an OutOfMemoryError past three quarters of the free memory
(MemAvailable, or less under a cgroup memory.max). loadImages sizes the
batch from the file headers and refuses it before decoding anything, and
holds the decodes in flight to what is left; renderChain and renderFrames
refuse a canvas at 24 bytes a pixel, plus any picture a Path param loads.
The interface keeps a refused batch's paths, so saving the project never
drops them. Version 0.6.1.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Si
2026-09-26 18:31:53 +02:00
co-authored by Claude Opus 5.5
parent 385617781e
commit ea59db5acd
13 changed files with 401 additions and 4 deletions
+9
View File
@@ -68,9 +68,18 @@ struct LoadProgress {
std::atomic<bool>* cancel = nullptr;
};
// The pixel count of an image file from its header alone, without decoding
// it; 0 when the header cannot be read.
std::size_t imageFilePixels(const std::string& path);
// Loads every path, collecting rather than throwing on individual failures.
// When `progress->cancel` is set the remaining paths are skipped, so the result
// is short and should be discarded rather than used.
//
// Before decoding anything the whole batch is sized from the file headers,
// and a batch that would not fit in the free memory throws OutOfMemoryError
// (core/memory.hpp) with nothing loaded; the decodes that run at once are
// also held to what is left over.
std::vector<Image> loadImages(const std::vector<std::string>& paths,
std::vector<LoadFailure>& failures,
const LoadProgress* progress = nullptr);