From 30eae4cf86f9d4bb745ebaff141bc3f67ce230a6 Mon Sep 17 00:00:00 2001 From: Etienne Lescot Date: Thu, 3 Sep 2026 20:58:50 +0200 Subject: [PATCH 1/2] perf(cli): give CLI windows their own renderer entry instead of the editor's MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A headless `openscreen export` costs 1.04x the ffmpeg floor instead of 2.00x. On the benchmark's 60 s clip that is 18.9 s instead of 36.4 s, and the output is byte-identical. WHAT WAS HAPPENING. `loadRunnerWindow` pointed every CLI window at `index.html`, the editor's entry. That entry imports `App.tsx`, so an export window loaded the whole editor module graph — 1.8 MB of JS across index, react-vendor and video-processing — before it could run. All of it sits inside the interval the stopwatch is running, because the CLI emits `started` as soon as the window is created. What the window actually renders is a `
` with one line of text while a runner calls the native compositor. MEASURED, Mac mini M1 / macOS 26.5, from inside the renderer: before after domInteractive 3887 ms 15 ms entry module evaluated 3946 ms 29 ms dom-ready (main process) 4103 ms 219 ms the whole runExport 24 ms 24 ms Everything after the module graph was already fast. The prologue — load the project, probe the screen and camera dimensions, reach the native call — is 24 ms, of which the two `