Overview

TinyFX documentation

This directory is the canonical TinyFX manual. It replaces the historical root-level DESIGN.md and ARCHITECTURE.md, which remain only as short compatibility redirects for existing links.

TinyFX is a type-checked, garbage-collected language for CPU orchestration and GPU rendering/compute. A single Rust frontend validates a program and feeds three execution-oriented outputs: TinyFX VM bytecode, WGSL plus rendering blueprints, and readable TypeScript/ESM plus WebGPU blueprints.

The repository's implementation and tests are the source of truth. This manual describes the supported public model; the generated operation catalog is the authoritative signature and target-availability reference.

Start here

  • Getting started — install, run, check, and build a first program.
  • Language, types, and functions — source syntax and semantic rules.
  • GPU programming — shaders, resources, drawing, compute, depth, feedback, and profiling.
  • Structured advanced compute — retained workspaces, atomics, append lists, deterministic operations, and GPU-resident counts.
  • Runtime and assets and media — lifecycle, environment, input, UI, persistent storage, cameras, assets, and platform services.
  • Tooling — CLI, formatter, LSP, VS Code, browser package, and playground.

Implementation manual

  • Architecture — target matrix, workspace, and ownership boundaries.
  • Compiler — checked frontend, semantic tables, stage analysis, and sibling lowerings.
  • VM and binary programs — bytecode, heap/GC, host boundary, and .tfxb.
  • Renderer and browser execution — frame model, blueprints, resource ownership, and platform/core split.
  • Testing — the evidence expected for language, renderer, and browser changes.

Reference material

Pure reference material is deliberately kept in refs/:

Documentation conventions

Source snippets are TinyFX unless labelled otherwise. A statement that is only true for native, browser-WASM, or generated TypeScript/WebGPU says so. When a feature has detailed overloads, capability conditions, or backend evidence, link to the operation catalog instead of maintaining a second hand-written signature list.

The repository intentionally keeps the manual separate from planning and historical implementation notes. Use LINEAR.md for active project workflow, not as a language reference.