The preview path meets its budget by removing work. The author's own list is the giveaway: shed computational accuracy, downsample texture resolutions, drop non-essential pipeline stages [4]. Export inverts every one of those, because on the export path latency stops mattering and spatial fidelity, temporal coherence, colour space precision and serialisation take over [5]. So a button that calls the preview renderer with a larger target size has to restore the textures and the passes the preview deleted, in the same context, while the interactive graph is still resident. The allocation that kills the tab is not one frame. It is the re-enabled passes plus the buffers you are holding while you serialise.
The harder half is the clock, and it does not live in the exporter. Any node driven by `performance.now()` drifts when heavy GPU execution drops frames, and the article's stated symptoms are temporal stuttering, audio-video drift, and non-deterministic visual output [6]. The proposed fix is a Virtual Time Controller that steps the timeline by an exact fixed fraction of a second, 1/30 or 1/60 per frame [7], which is 33.3 ms and 16.7 ms of virtual time [13]. A 120 fps preview frame gets 8.3 ms of real time [14], roughly a quarter of the 30 fps export step [15]. Nothing requires a 33.3 ms step to consume 33.3 ms of wall clock, which is the entire point of virtualising it.
That step is only worth anything if the nodes cooperate. The contract the article sets is that every node be pure and stateless with respect to wall-clock time, so the same frame index returns the same pixel buffer [8], with floating-point accumulation across compute passes named as the thing that breaks temporal coherence [9]. An exporter cannot enforce that from outside. Each second of 30 fps output is 30 renders that all have to honour it [16], and the audit is per node, in a graph you have already shipped.
The readback is the visible freeze. `canvas.toDataURL()` and `canvas.toBlob()` force the browser to read pixels back out of the GPU frame buffer, synchronously or semi-synchronously [10]. Do that on the main thread at export resolution and the UI is gone until it finishes. The article's answer is a stack of WebGPU, OffscreenCanvas, deterministic virtual timelines, zero-copy memory mapping and multi-format serialisation to MP4, SVG and PDF [11].
Treat the crash as a claim about someone else's workload, because that is what it is: the scenario is narrated rather than measured, with no browser build, GPU or peak-memory figure in the supplied text, which breaks off mid-sentence on the readback discussion [12]. For it to transfer, your export has to share the preview's GPU context and thread, your nodes have to read wall-clock time, and your capture has to route through `toDataURL` or `toBlob`. If your graph is already a pure function of frame index and renders in a worker, the described implosion belongs to a different codebase. What I would accept without a measurement is the ordering argument, since the friction the article calls permanent [1] is cheap to design around before the node library exists and expensive afterwards.
