screentinker/server/lib/image-ops-core.js
screentinker 13c9c67335
Drop sharp: pure-JS image ops on a worker thread (#263)
* spike: replace sharp with pure-JS image ops (jimp + jsquash WASM)

Removes the last native dependency from the ingest path, so the server no longer
needs a per-platform/per-ABI prebuilt to thumbnail an image. Motivated by getting
the server onto hardware with no toolchain, but the ABI tax is paid on every
install — it is the same failure class lib/preflight-deps.js exists to explain.

lib/image-ops.js is the whole surface: metadata() and writeThumbnail(), which are
the only two things ingest ever asked sharp for.

Format parity holds. jpeg/png/gif/tiff/bmp are native to Jimp; webp and avif go
through @jsquash WASM, whose bundled .wasm must be compiled by hand because the
packages locate it with fetch(file://) and Node has no file:// fetch — the only
symptom otherwise is a bare "fetch failed". heic is unsupported, as it already
was: sharp advertises heif but its prebuilt libvips refuses HEVC.

#170 is preserved by a different mechanism. Jimp applies EXIF orientation at
decode and rewrites the tag to 1, so metadata() reports display dimensions and
imageDisplayDims() runs as a no-op instead of swapping W/H a second time. The
helper stays in the path so the rule keeps living in one place.

Verified: 1643/1643 tests pass, and ingest was exercised in a child process with
node_modules/sharp moved aside — jpeg, EXIF-rotated jpeg, png, webp, avif, gif
all measured and thumbnailed correctly, corrupt input still yields nulls with no
phantom thumbnail_path.

KNOWN BLOCKER, do not ship as-is: Jimp is pure JS on the main thread, where sharp
handed work to a libvips threadpool. A 12MP photo goes 65ms -> 1079ms, and the
event loop stalls for 1003ms of it (sharp: zero stalls). thumbnail-backfill.js
walks a whole library at boot, so this reproduces #240 exactly — blocked loop,
missed heartbeats, panels marked offline, reconnect churn. Needs a worker_thread
offload before this is viable; image-ops.js is the seam for it.

* Run image decoding on a worker thread

Fixes the blocker the previous commit shipped with. Pure-JS decoding costs ~1s of
solid CPU for a 12MP photo, and in-process that is not a slow upload but a stalled
event loop — no heartbeats, no socket traffic. thumbnail-backfill.js walks a whole
library at boot, so it reproduced #240 (blocked loop -> missed heartbeats -> panels
offline -> reconnect churn) from our own maintenance. sharp never did this because
libvips works on a threadpool.

image-ops.js is now a dispatcher over image-ops-worker.js; the work moved unchanged
to image-ops-core.js, so callers and their failure contract are untouched.

Measured on a 12MP photo: 1079ms wall with the loop stalled 1003ms, to 1881ms wall
for two ops with ZERO stalls and 185 timer ticks serviced. Wall time is worse and
that is fine — it is off the main thread now.

Design notes, all load-bearing:
  - ONE JOB AT A TIME. A decoded 12MP bitmap is ~48MB of RGBA; overlapping jobs
    multiply peak memory by queue depth, which is the wrong failure on the small
    targets this change exists to reach. Costs no throughput — the work is CPU-bound
    and one busy worker already saturates its core.
  - unref'd while idle, ref'd only in flight. Otherwise scripts/backfill-rotation-
    dims.js never exits and `node --test` hangs forever. Verified: a CLI-style run
    exits in 104ms, code 0.
  - decode failures reply as messages, so one bad upload cannot tear down the worker
    and take unrelated queued jobs with it.
  - in-process fallback if a thread cannot be had, warned rather than silent.

test/image-ops.test.js pins the loop-liveness property, which no functional test
would catch. Its thresholds were mutation-tested against the inline path: the first
version passed there too (4MP stalls only ~355ms, under a non-flaky threshold), so
the fixture is 12MP and the thresholds sit in the gap between the two behaviours —
worker ~90 ticks/~0ms, inline ~3 ticks/~897ms. It now fails inline, as a guard must.

1647/1647 pass. Ingest re-verified with node_modules/sharp moved aside.

* Measure and thumbnail an image from a single decode

Ingest asked for metadata() then writeThumbnail(), which decoded the file twice.
That pairing was free under sharp, whose .metadata() only parses the header, but
every decode here is a full one — ~1s for a 12MP photo — so the naive translation
doubled the most expensive thing on the ingest path.

image-ops.measureAndThumbnail() returns both from one decode. Full ingest of a
12MP photo: 2 decodes/~1.9s -> 1150ms, still with zero event-loop stalls.

The subtlety is the failure contract. In the two-call version width and height
were assigned BEFORE the thumbnail was attempted, so a failed thumbnail still left
usable dimensions on the row — the player needs them to letterbox. Merging naively
would have turned any thumbnail failure into total metadata loss. So a WRITE
failure is reported ({thumbnailWritten:false, thumbnailError}) with the dimensions
intact, and the caller sets thumbnail_path only when the write succeeded, keeping
the phantom-path discipline. A DECODE failure still throws — there is nothing to
report about an unreadable image.

backfill-rotation-dims.js deliberately keeps the separate calls: it probes every
image row but regenerates a thumbnail only for the few whose dimensions changed,
so pairing them there would decode files it has no reason to thumbnail.

Tests count decodes rather than timing them — an exact property, and a wall-clock
comparison would be flaky under load. The count filters for reads of the file under
test: Node's ESM loader also goes through fs.promises.readFile, so a raw call count
picks up jimp's and the WASM codecs' lazy loading and reads 30 instead of 1.

1649/1649 pass. Ingest re-verified across all 7 formats with sharp moved aside.

* Dockerfile: sharp is no longer a production dependency

--omit=dev now leaves it out entirely; better-sqlite3 is the only native module
the builder stage still needs a toolchain for.
2026-08-13 11:40:13 -05:00

143 lines
6.7 KiB
JavaScript

'use strict';
/*
* Pure-JavaScript image operations — the two things the ingest path ever asked sharp for:
* measure an image, and write a thumbnail.
*
* THIS FILE IS THE WORK, NOT THE ENTRY POINT. Callers use ./image-ops, which runs these on a
* worker thread; everything here is CPU-bound pure JS that would otherwise stall the event loop
* for ~1s per 12MP photo. Requiring this module directly is only correct inside the worker (or in
* image-ops' inline fallback). See ./image-ops for why.
*
* WHY NOT SHARP: sharp is a native module wrapping libvips. That costs us a prebuilt binary per
* platform/ABI, and when there isn't one (or Node moves ABI) the failure is
* ERR_DLOPEN_FAILED/NODE_MODULE_VERSION at require time — the same class of breakage
* lib/preflight-deps.js exists to explain for better-sqlite3. Nothing in here is native, so the
* server runs anywhere Node runs, including the embedded targets that have no toolchain.
*
* FORMAT COVERAGE vs the sharp it replaces:
* jpeg png gif tiff bmp Jimp, natively
* webp avif @jsquash/* — WebAssembly, bundled, no network (see wasmDecode below)
* svg never reaches here; callers thumbnail an SVG with itself
* heic unsupported — and it already was. sharp lists `heif`, but its
* prebuilt libvips has AV1 only and refuses HEVC ("Unsupported
* compression"), so .heic uploads have never produced a thumbnail.
*
* ORIENTATION (#170): Jimp applies EXIF orientation when it decodes and rewrites the tag to 1,
* so what comes back is already DISPLAY dimensions — the rotation sharp needed an explicit
* .rotate() for. metadata() therefore reports orientation 1 and lets imageDisplayDims() run as a
* no-op rather than swapping W/H a second time. Report the tag honestly and that helper stays
* correct for any future decoder that does NOT auto-orient.
*/
const path = require('path');
const fs = require('fs');
const { sniffMime } = require('./upload-sniff');
// Jimp is ESM-first but ships a CJS entry; require() is fine and keeps this file loadable from
// the CommonJS server. Deferred so a caller that never touches an image never pays for it.
let _jimp = null;
function jimp() {
if (!_jimp) _jimp = require('jimp');
return _jimp;
}
/*
* @jsquash's decoders are browser-first: they locate their .wasm with
* `fetch(new URL('...wasm', import.meta.url))`. Under Node that URL is a file:// one and Node's
* fetch does not implement file://, so the bundled binary never loads and the only symptom is a
* bare "fetch failed". The binary IS on disk in the package — read and compile it ourselves, then
* hand the Module to init(). No network, at install time or after.
*/
const WASM_CODECS = {
'image/webp': { pkg: '@jsquash/webp', wasm: '@jsquash/webp/codec/dec/webp_dec.wasm' },
'image/avif': { pkg: '@jsquash/avif', wasm: '@jsquash/avif/codec/dec/avif_dec.wasm' },
};
const decoderCache = new Map();
async function wasmDecode(mime, buf) {
const spec = WASM_CODECS[mime];
if (!spec) return null;
if (!decoderCache.has(mime)) {
decoderCache.set(mime, (async () => {
const mod = await import(`${spec.pkg}/decode.js`);
await mod.init(await WebAssembly.compile(fs.readFileSync(require.resolve(spec.wasm))));
return mod.default;
})());
}
const decode = await decoderCache.get(mime);
return decode(buf); // -> ImageData-ish { data, width, height }
}
/*
* Decode to a Jimp image whatever the format. Reuses sniffMime rather than carrying a second copy
* of the magic-byte table — routes/media.js already duplicating it once is noted there as a smell.
* Throws on anything undecodable, which is the contract callers already handle (a failure yields
* null metadata and no thumbnail, never a lost upload).
*/
async function readImage(src) {
const buf = await fs.promises.readFile(src);
const mime = sniffMime(buf);
if (WASM_CODECS[mime]) {
const raw = await wasmDecode(mime, buf);
if (!raw) throw new Error(`no decoder for ${mime}`);
return jimp().Jimp.fromBitmap({ data: Buffer.from(raw.data), width: raw.width, height: raw.height });
}
return jimp().Jimp.read(buf);
}
/*
* Display dimensions, shaped like the sharp metadata the callers already destructure.
* orientation is 1 because the decode above already applied it — see ORIENTATION note at the top.
*/
async function metadata(src) {
const img = await readImage(src);
return { width: img.bitmap.width, height: img.bitmap.height, orientation: 1 };
}
/*
* Resize-and-encode an ALREADY DECODED image. Never upscales: sharp's resize() would enlarge a
* small source, but a thumbnail bigger than its original is pure waste and callers only shrink.
* Mutates img, so measure before calling.
*/
async function encodeThumbnail(img, destPath, width, quality) {
if (img.bitmap.width > width) img.resize({ w: width });
await fs.promises.writeFile(destPath, await img.getBuffer('image/jpeg', { quality }));
}
/*
* Write a JPEG thumbnail `width` px wide, aspect preserved — sharp's
* .rotate().resize(width).jpeg({quality}).toFile(). Rotation is implicit in the decode.
*/
async function writeThumbnail(src, destPath, width, quality = 70) {
await encodeThumbnail(await readImage(src), destPath, width, quality);
}
/*
* Measure AND thumbnail from a SINGLE decode — what ingest actually wants.
*
* Calling metadata() then writeThumbnail() decodes the file twice. That was free under sharp,
* whose .metadata() only parses the header, but here every decode is the full ~1s of a 12MP
* photo, so the naive pairing doubled the most expensive thing the ingest path does.
*
* A thumbnail failure must NOT discard the dimensions: they are independently useful (the player
* needs them to letterbox correctly) and that is how the two-call version behaved, since width and
* height were already assigned before the thumbnail was written. So the write is reported, not
* thrown — and the caller assigns a thumbnail_path only when thumbnailWritten is true, keeping the
* phantom-path discipline that stops the UI requesting a file that was never created.
* A DECODE failure still throws: there is nothing to report about an unreadable image.
*/
async function measureAndThumbnail(src, destPath, width, quality = 70) {
const img = await readImage(src);
const measured = { width: img.bitmap.width, height: img.bitmap.height, orientation: 1 };
try {
await encodeThumbnail(img, destPath, width, quality);
return { ...measured, thumbnailWritten: true, thumbnailError: null };
} catch (err) {
return { ...measured, thumbnailWritten: false, thumbnailError: err && err.message ? err.message : String(err) };
}
}
module.exports = { metadata, writeThumbnail, measureAndThumbnail, readImage };