Client-side media: Bundle JPEG XL (JXL) support directly into Gutenberg#77570
Closed
adamsilverstein wants to merge 2 commits into
Closed
Client-side media: Bundle JPEG XL (JXL) support directly into Gutenberg#77570adamsilverstein wants to merge 2 commits into
adamsilverstein wants to merge 2 commits into
Conversation
Bundle vips-jxl.wasm into the Gutenberg vips worker so client-side JPEG XL processing works out of the box without a separate plugin. - packages/vips: Re-add VipsJxlModule import, include vips-jxl.wasm in dynamicLibraries, wire it through locateFile, and set effort=3 on JXL saves (default of 7 is too slow for interactive use). Add image/jxl to supportsQuality. - packages/upload-media: Add image/jxl to CLIENT_SIDE_SUPPORTED_MIME_TYPES, add 'jxl' to VALID_IMAGE_FORMATS and the ImageFormat type, and widen the vipsConvertImageFormat wrapper's output type union. This is an alternative approach to #76990, which ships the same WASM module via a canonical plugin. Opening this PR to let the size bot quantify the bundle impact of shipping the module by default. Refs #76981.
|
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: +1.1 MB (+14.08%) Total Size: 8.92 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in 45f0531. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/25137115768
|
8 tasks
Resolve CHANGELOG conflicts in packages/upload-media and packages/vips by preserving Unreleased JXL entries above the new 0.30.0/1.5.0 release sections from trunk.
Member
Author
|
Closing in favor of the lazy loading approach in #77584 where we still ship the jxl support directly with Gutenberg, but only load it when/if needed. |
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.
Summary
Alternative approach to #76990: instead of shipping the JXL WASM module via a canonical plugin, bundle
vips-jxl.wasmdirectly into the Gutenberg vips worker so client-side JPEG XL processing works out of the box with no additional plugin required.Opened primarily so the size bot can quantify the bundle impact of shipping JXL by default. We can compare the tradeoffs between this and the canonical-plugin approach on the actual CI numbers.
Closes #76981 (alternative).
Bundle size impact
Measured locally from
npm run build:build/modules/vips/worker.min.jsThis matches the ~3.1 MB figure noted in #76639, which removed
vips-jxl.wasmfrom the worker and in #76981.Changes
@wordpress/vipsVipsJxlModuleimport (inlined base64 WASM).vips-jxl.wasmindynamicLibraries.locateFile.image/jxltosupportsQuality().effort=3on JXL saves (libvips default of 7 is too slow for interactive use).@wordpress/upload-mediaimage/jxltoCLIENT_SIDE_SUPPORTED_MIME_TYPES.jxltoVALID_IMAGE_FORMATSand to the exportedImageFormattype.vipsConvertImageFormatwrapper output-type union to includeimage/jxl.Comparison to #76990 (canonical plugin approach)
Test plan
npm run buildand verifybuild/modules/vips/worker.min.jsis ~16.1 MB..jxlfile and verify it's processed client-side (resize, compress, thumbnails).