gifsave: ensure return code is propagated #4344
Open
+78
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Whilst investigating lovell/sharp#4257 I discovered that
vips_sink_disc
appears to always return zero duringvips_foreign_save_cgif_build
even whenvips_foreign_save_cgif_sink_disc
returns a non-zero return code. It feels like a bit of a race condition, and I think this is because we need to have the entire input in memory before the CPU-intensive quantisation takes place.This PR adds a new
aborted
property to track any non-zero return code, which then allows for things like aneval
callback. The call tovips_image_eval
occurs for each frame just after the image is remapped to the new palette as this is the most CPU-intensive section. I'd be happy to move thevips_image_eval
call to a different location if required, or perhaps it might be better to add multiple calls given the CPU-intensive nature of quantisation as a whole.