Performance on lower-memory devices

What the adaptive profile changes

Varve watches the duration of real animation frames and moves between four tiers:quality, balanced, performance, and constrained. A tier must be observed for ten frames before a switch, with a thirty-frame cooldown, so the interface does not oscillate between settings.

The reduced render scale is used during eligible interactions. Pan and zoom may also temporarily reproject the latest worker frame while a replacement is in flight; that image can look soft or incomplete until the current state is painted. A declined or failed worker submission schedules the main-thread renderer. Once input stops, Varve requests an authoritative frame at the selected quality. Warm refinement targets are 500 ms for ordinary work and 1 s for heavy work after required assets are ready. They are targets, not guarantees; cold image and font readiness can extend the wait and is not quantified in the published evidence. Exports and print output render through their own full-fidelity paths, independent of the navigation preview.

Device-memory hints can raise the floor before any frame is measured: a browser reporting 2 GB or less with a substantial document starts in constrained; 4 GB or less with a very large document starts in performance. These hints are coarse, browser-provided values. They are never treated as the amount of RAM available to the tab.

What it does not change

• Document and output: a navigation preview does not rewrite artwork or saved geometry. Exports and print output use their own full-fidelity paths; preview quality does not set export quality.
• Your document: the profile changes rendering cost, not geometry, text, effects, or undo history.
• Presentation and compute are separate: Canvas2D remains the dependable display path. Opt-in WebGPU draws only shapes painted with a single solid color (rectangles, circles, ellipses) when the frame reaches the compositor and device initialization succeeds; a ready adapter alone does not prove GPU drawing or a speedup. If the device is lost mid-session, Canvas2D keeps drawing while WebGPU is retried automatically. Native desktop GPU compute is separate and limited to offscreen resampling and explicit asynchronous effect consumers, plus AI inference through a verified GPU execution provider on supported models. The current interactive effect preview and export replay remain on the software reference path. Background removal reports which provider actually ran and keeps a CPU fallback. The current release does not select an NPU: a product specification, host device, browser request, or Linux device node is not enough. A future NPU route must have a compatible provider runtime, driver, model, and observed execution on the actual process path.
• Manual quality control: the Performance tab offers Automatic (recommended) or Full resolution while navigating; it does not expose a render-scale slider. Automatic responds to measured frame pressure; Full resolution is a fidelity choice rather than a promise of a fixed frame rate or refinement deadline.

Practical workload guidance

• Comfortable without special care: a few hundred nodes of shapes and text, a handful of images at screen resolution, and normal layer structures — the same scale as the built-in sample document.
• Expect adaptation: documents around a thousand mixed nodes, several large images, or concentrated effects can push the profile toward performance tiers. Responsiveness still depends on scene complexity, asset readiness, backend, and available device time; a preview may miss its refinement target.
• Treat as stress, one at a time: dozens of 4096×4096 images, tens of thousands of path points, or long effect stacks. These are deliberate worst cases, not everyday documents, and combining them multiplies cost.
• Browser-local limits: the public demo at varve.studio is served from GitHub Pages, which cannot configure the cross-origin isolation headers required for shared-memory WASM. Multi-threaded WASM is unavailable in that deployment. This is a limit of the current public host, not every possible browser deployment; WASM and graphics capabilities also depend on the browser runtime. Use Settings → Performance → Platform capability report to inspect the current session. No general speed comparison with desktop is published without a matched device and workload.
• Background work yields: thumbnails, raster pyramids, and semantic indexing are bounded, cancellable, and paused while the page is hidden or frozen. Chrome can discard a tab — including an installed web app on ChromeOS — without firing an unload event, so recovery points are written while you edit and an explicit save remains the durable copy.

Failure modes Varve deliberately avoids

These failures have been reported by users of design tools. Varve has safeguards for several of them, but those safeguards do not mean every workload meets its target. The examples describe regression-tested behavior and known gaps, not device-wide guarantees.

• A preview that misses its refinement target: Varve schedules an authoritative redraw after input, with warm targets of 500 ms for ordinary work and 1 s for heavy work once required assets are ready. A slow device, busy scene, or cold image/font can take longer; misses remain part of the evidence rather than being discarded.
• Full-resolution decode of offscreen images: visible images are bucketed to power-of-two proxies governed by a decoded-byte budget, so one oversized image cannot pin the working set at full resolution.
• Background rewrites of unchanged data: automatic backups are skipped when the document JSON matches the last backup, duplicate untitled recovery writes were removed, recovery storage is byte-capped, and permanently deleting a file or version reclaims its content-addressed JSON.
• Work loss on tab discard: Chrome documents that no event fires on discard; recovery points are written while you edit, and a reload or discard restores the latest point. An explicit save is still the durable copy.
• Silent model downloads or cloud fallback: optional models are downloaded only after you start the operation, with download/storage size and an estimated peak working memory shown; images are never uploaded to a paid endpoint behind the capability gate.

Optional AI model costs

Core editing never depends on a model download. Optional on-device features are capability-gated, and the model dialogs report the download/storage size and an estimated peak working memory separately. Those memory numbers are estimates with a visible caveat, not device measurements. The largest optional models are roughly a gigabyte each; they are downloaded explicitly, never bundled into the editor's first screen, and should be treated as the single most expensive background operation on a 4–8 GB device.

In the browser, model files are streamed into local staging storage and checked before they become ready. A failed or cancelled transfer is not presented as installed. A successful enhancement is saved as document pixels, so reopening and exporting the result does not require the model again.

Chromebook routes have different limits

The browser demo/PWA and the Linux desktop package run through different platform paths. The public demo is served from GitHub Pages and cannot enable the cross-origin isolation required for shared-memory WASM. A model download or successful settings probe does not establish that an optional model will fit the remaining working set on a Chromebook. Save before long work and use the capability report to see which provider actually ran.

Host-side Chromium emulation is regression evidence only. Physical Duet touch/pen, on-screen keyboard placement, suspend/resume, offline reopen, and export checks remain pending for both ChromeOS browser/PWA and ARM64 Crostini. See the Chromebook route guide for current package facts and setup steps.

Multitasking, storage, and power

• Memory is shared: on a Chromebook, ChromeOS, Android, the browser, and the Linux container draw from the same installed RAM. Closing unused tabs and applications is the most effective single action.
• Storage affects behavior: recovery copies and the offline app copy consume browser storage. Use Settings → Storage & Offline to see estimates and to clear disposable offline copies; never clear recovery copies while a document has unsaved edits.
• Power: sustained inference, large effects, and long pans use more CPU/GPU time and therefore more battery. No battery-duration figure is published for Varve; the reference device's 29 Wh battery is not a runtime promise.
• Updates and motion: updates are user-approved and never restart over unsaved work. Reduced-motion preferences are honored; decorative animation is paused when the page is hidden.

Settings worth knowing

• Settings → Performance: shows the current tier and frame diagnostics, and honors reduced motion.
• Settings → Storage & Offline: storage estimates, persistence request, recovery-copy count, and safe cleanup of offline app copies.
• Platform capability report: Settings → Performance → Platform capability report runs bounded local checks (graphics, worker, WASM, storage, files) and can be downloaded as JSON for a bug report. It is produced on demand and never uploaded.