Vips: Remove dead batchResizeImage and vipsBatchResizeImage exports#77975
Open
adamsilverstein wants to merge 1 commit intotrunkfrom
Open
Vips: Remove dead batchResizeImage and vipsBatchResizeImage exports#77975adamsilverstein wants to merge 1 commit intotrunkfrom
adamsilverstein wants to merge 1 commit intotrunkfrom
Conversation
The single-pass batch resize path was originally introduced in #76979 to decode the source image once and produce every sub-size from a single in-memory copy, with a per-thumbnail else branch as a fallback. #75888 (concurrent sideloads) then restructured generateThumbnails() so each sub-size dispatches its own queued ResizeCrop+Upload sideload item that runs in parallel. After that refactor neither the batch path nor the per-thumbnail fallback in private-actions.ts is wired up: the sideload queue performs the per-sub-size resize via vipsResizeImage, and batchResizeImage has zero callers in the repo. Drop the dead WASM-side batchResizeImage function in @wordpress/vips, the matching vipsBatchResizeImage main-thread wrapper, the worker API entry, the BatchResizeConfig/BatchResizeResult helper types, and the auto-generated README sections. The shared applyResizeAndCrop and buildSaveOptions helpers are retained because resizeImage still uses them. Fixes #77247
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -217 B (0%) Total Size: 7.94 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in 0dc20b7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25392656802
|
adamsilverstein
added
[Type] Bug
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What
Drops the unused single-pass batch resize path from
@wordpress/vips:batchResizeImage()(WASM-side, runs in the worker)vipsBatchResizeImage()(main-thread RPC wrapper)batchResizeImageentry in the worker API surfaceBatchResizeConfig/BatchResizeResultinterfacesThe shared
applyResizeAndCrop/buildSaveOptionshelpers are kept —resizeImage()still uses them.Closes #77247
Why
The batch path was added in #76979 to decode each source image once via
copyMemory()and emit every sub-size from a single in-memory copy, with a per-thumbnailelsebranch as a fallback. #77247 asked whether that fallback was dead code and whether the two paths could ever fail differently.While investigating I found that the question is moot: #75888 (concurrent sideload uploads) reorganised
generateThumbnails()so each sub-size dispatches its own queuedResizeCrop+Uploadsideload item, with the queue handling parallelism. As of trunk:packages/upload-media/src/store/private-actions.tsno longer imports or callsvipsBatchResizeImage— neither the batch path nor the fallback exists there anymore.vipsResizeImageoperation registered for theOperationType.ResizeCropstep.batchResizeImage/vipsBatchResizeImagehave zero callers anywhere in the repo (grep -rn "batchResize" packages/confirms).So the right resolution for #77247 is not to enumerate divergent failure modes, but to delete the orphaned batch resize API surface that's been left behind in
@wordpress/vips.Verification
npm run test:unit -- --testPathPattern="(upload-media|vips)"→ 209 tests pass.npm run lint:js -- packages/vips packages/upload-media→ clean.grep -rn "batchResize\|vipsBatch" packages/ --include='*.ts' --include='*.js'(excludingbuild-and bundledworker-code) returns only the new CHANGELOG entry.Related