Skip to main content

Rendering Architecture

heycreo uses one shared render core and two export targets. The Studio preview and both backends consume the same layout, text-fit, and element logic so what you see in the editor matches what gets exported.

Overview​

packages/studio-domain     editor document model
         │
packages/render-engine     shared render core
         │
    ┌────┴────────────────────┐
    │                         │
renderers/browser          renderers/remotion
(Playwright HTML)          (Remotion bundle)
PNG / JPEG / WebP / PDF    MP4 / WebM
    │                         │
    └──────────┬──────────────┘
               │
         frontend Studio
         (live canvas / Player)
PathRole
Studio (frontend)Live preview and editing
packages/render-engineElements, auto-layout, text fitting, animation math
renderers/browserSingle-file HTML for image/PDF export (and mobile WebView)
renderers/remotionComposition bundle for video export

The API worker picks the target via render-selector: images/PDF prefer the browser renderer; video uses Remotion when its bundle is available.

Live Preview​

While editing templates you see changes instantly:

  • Real-time updates as you modify text, images, or layout
  • Interactive editing with immediate visual feedback
  • Same render core as export (not a separate screenshot path)

Export​

  • Images: PNG, JPEG, WebP via the browser renderer
  • PDF: browser renderer (+ optional CMYK prepress via Ghostscript)
  • Video: MP4 / WebM via Remotion
  • Batch: multiple sizes/exports through the worker queues

Consistency​

  • Shared engine under packages/render-engine
  • Visual regression snapshots gate both render targets in CI
  • Preview and export are meant to stay in lockstep; report any drift

Best Practices​

  • Preview first — verify the design in the Studio before exporting
  • Test different content lengths — especially with auto-resize text
  • Spot-check exports after changing the render engine or a renderer

See also​