The PracticalKit RGBV3D encoder runs client-side via @rgbv3d/core compiled for the browser. That keeps uploads off our servers but imposes hard ceilings: JavaScript heap limits, WASM linear memory growth, and single-threaded execution on main stream paths.
Memory scales roughly with width × height × channels for decode buffers, plus temporary vectors during encode. A 6000×4000 RGBA canvas rasterized to RGB24 already allocates on the order of tens of megabytes before codec structures allocate. Mobile Safari and embedded browsers fail earlier than desktop Chrome. We document “try half resolution first” on the tool guide because it is the most common real fix.
WASM SIMD and threads are not assumed. Features available in native CLI builds may lag the web bundle. If encode stalls without an error, open devtools performance: long tasks over 50ms block UI and may trigger tab kill on low-memory devices.
Comparison to server-side tools: a cloud compressor can stream tiles and use multiple cores. We deliberately trade that for privacy. For batch archives of hundreds of masters, use the CLI from /rgbv3d/download/; use the web tool for spot checks, teaching, and ad-hoc verification.
Testing methodology we recommend: start at 1080p-equivalent assets, measure encode time and peak memory in devtools, then scale up. Pair with the PNG round-trip article’s pixel diff script. If browser limits bite, split spritesheets or export PNG from the image tool after decode—compatibility still beats heroic in-tab megapixel experiments.
Future roadmap items (SIMD, worker offload) are listed on /rgbv3d/roadmap/ with no ship dates. Until then, treat the browser tool as a faithful reference implementation with honest resource bounds—not a replacement for batch transcode farms.
2026-06-12