@solidrt/core 0.0.49 → 0.0.51

package/AGENTS.md

@@ -7,6 +7,15 @@ trust this file and the types in src/types.d.ts and jsx-runtime.d.ts.
 SolidRT is a custom SolidJS renderer: it paints through a Rust runtime, not the
 DOM. There is no HTML, no CSS cascade, no `className`.
 
+Two companion files carry the depth this one leaves out; read the one that
+matches the work before starting it:
+- agents/painting.md - what you paint with, and what replaces each CSS
+  reflex. Read before styling a screen: a background, a gradient, a shadow,
+  an effect, vector art, a chart.
+- agents/performance.md - the performance model, in order of leverage. Read
+  before writing any per-frame code, any animation, or anything that writes
+  properties in a loop.
+
 ## The window is device-sized - design fluid
 
 A SolidRT window is host-sized and resizable, and the SAME app runs on phones,
@@ -135,6 +144,8 @@ Peer deps @solidjs/signals and @solidjs/universal must match (currently
   box center; a d-view has no box). To scale a detached group around its
   content's center, set the origin explicitly in pixels, e.g.
   `originX={100} originY={50}` for content drawn in a 200x100 local space.
+  Avoid pct()/keyword origins on a d-view - they resolve against the box
+  inherited from the nearest laid-out ancestor.
 
 - Layout-affecting vs not (this matters for per-frame work). Props fall in three
   buckets, split by where they take effect:
@@ -159,6 +170,18 @@ Peer deps @solidjs/signals and @solidjs/universal must match (currently
   expression container preserves it - `<d-text>{"one    two"}</d-text>` - and
   `\n` inside one produces a hard line break.
 
+- Rich text: `<span>` inside `<text>` restyles a run (`color`, `fontFamily`,
+  `fontSize`, `fontWeight`, `fontStyle`, `lineHeight`,
+  `textDecoration="underline"`); spans nest and
+  inherit inward from the `<text>`. Never lay a paragraph out word by word in
+  a wrapping row to mix styles - one `<text>` with spans wraps as a whole.
+  A span is content, not a box (no layout or `d-` form, no size, no
+  bounding box; it takes its parent's form). A `<span>` takes
+  pointer handlers (a link is a span, hit per line it spans), and any other
+  element child of `<text>` (`<view>`, `<texture>`, `<path>`, ...) is an
+  inline atom flowing with the words as one unbreakable box on the baseline;
+  give it margins for spacing, since JSX trims the whitespace around it.
+
 - Events: there is NO `onClick`/`onPress`. A "button" is a `<view>`/`<rect>`
   with `onPointerDown`. Handlers: onPointerDown/Up/Move/Enter/Leave, onWheel,
   onKeyDown/Up, onTextInput, onFocus/onBlur. Text entry: focus a node with an

package/README.md

@@ -53,7 +53,7 @@ Optionally, create a `tsconfig.json` to enable type recognition for SolidRT elem
 
 ## API
 
-See [docs/core.md](https://github.com/wellawaretech/solidrt/blob/main/docs/core.md) for the full API reference.
+See [docs/20-core](https://github.com/wellawaretech/solidrt/blob/main/docs/20-core/index.md) for the full API reference.
 
 ## License
 

package/agents/painting.md

@@ -0,0 +1,61 @@
+# What you paint with (there is no CSS layer)
+
+Read this before building any screen whose look matters: a background, a
+decoration, an effect, a chart, anything you would have reached for CSS for.
+
+Layout and props are half the model. There is no stylesheet: no filters, no
+box-shadow, no keyframes, no canvas. The visual range a web app gets from CSS
+comes from the tiers below instead, and reaching past tier 1 is ordinary
+app-building here, not optimization - a screen built only from view
+backgrounds and text is using a fraction of the runtime. Pick the tier the
+CONTENT calls for, not the one that looks safest.
+
+1. Laid-out elements - `<view>`/`<text>`, with `<rect>` (or a filling
+   `<d-rect>` child) for background, border, radius. The structure of a
+   screen, not its finish.
+2. Vector art, detached from layout - `d-path`/`d-rect`/`d-oval`/`d-line`,
+   whose `color` takes a gradient (createLinearGradient /
+   createRadialGradient) and which honour `blendMode`, plus `parseSvg` to
+   draw a whole SVG document as one subtree. Free-form shapes, decoration,
+   diagrams, charts, anything positioned rather than flowed. Examples:
+   parse-svg, detached-positioning, text-paint-styling.
+3. GPU textures - `createShaderTexture` puts a fragment shader in a
+   `<texture>` (moving gradients, noise, glow, dissolves, a background that
+   is alive), `createPipelineTexture` draws geometry you generate yourself
+   (particles, point clouds, splats), and the `shader` prop post-processes
+   content that already exists: on a `<view>` it grades, warps or dissolves
+   that subtree, on `<window>` the whole frame. Stack `<texture>` elements
+   with `blendMode` to combine passes. Examples: gpu-shader, gpu-particles,
+   gpu-pipeline, gpu-instancing, gpu-texture-blend, view-shader,
+   window-shader.
+4. 3D scenes - add `@solidrt/3d` (not a scaffold dependency): meshes,
+   materials and a camera declared as Solid components, rendered into a
+   texture that sits in the UI tree like any other element.
+
+Tier 3 is cheaper than it looks. A shader costs one property write per frame
+no matter how complex the effect, which is why the performance model
+(agents/performance.md) reaches for it first rather than as a last resort.
+
+## Web reflexes and what replaces them
+
+- gradient background -> a gradient `color` on a `d-rect` (gradients are
+  paint values, usable anywhere a color is)
+- `filter: blur/grayscale/hue-rotate`, and any "make this look processed" ->
+  a `shader` on the view (requires repaintBoundary="snapshot"), or on
+  `<window>` for the whole frame
+- `box-shadow` / `text-shadow` / glow -> no shadow prop exists: draw an
+  offset `d-*` shape under the content, or a view shader with `outset` (the
+  transparent margin an effect bleeds into)
+- `backdrop-filter` -> no equivalent. A view shader sees only its own
+  subtree's pixels, never what is behind it. Frost the whole frame with a
+  window shader, or fake the layer with your own content
+- CSS `transition` -> the `transition` prop: declare it on the element and
+  keep writing targets; the runtime animates natively (performance rule 1)
+- `@keyframes` -> a `transition` prop when the motion is target-shaped;
+  `onFrame` writing a signal for genuinely procedural sequences; a `uTime`
+  uniform when the animation is continuous and visual
+- `<canvas>` 2D -> `d-*` primitives (rebuild one `d-path` string per frame
+  rather than animating N elements)
+- `<canvas>` WebGL, three.js -> `createPipelineTexture`, or `@solidrt/3d`
+- video background, animated hero, particle field -> a shader texture; this
+  is the case the runtime is built for

package/agents/performance.md

@@ -0,0 +1,216 @@
+# Performance model (JS is the slow lane)
+
+Read this before writing any per-frame code, any animation, or anything that
+writes properties in a loop.
+
+The JS engine is interpreted and every property write crosses an FFI boundary
+into the runtime, so per-frame JS work is the expensive path while GPU work is
+nearly free. That holds on desktop and on current mobile hardware; "Where GPU
+work stops being free" below is where it does not. The design answer is not
+"write less JS" but "keep JS off the per-frame path": the platform animates
+(transitions), caches (repaint boundaries), shades (GPU) and computes
+(isolates, wasm) natively, and JS stays the coordinator that sets targets.
+Rules, in order of leverage:
+
+1. Motion between states (position, size, opacity, transform components,
+   solid colors, enter/exit) belongs in a native transition, never in
+   per-frame JS. Declare `transition` on the element and keep writing
+   targets the ordinary way; the runtime interpolates every frame on the
+   Rust side, so JS runs only when a target changes and the running
+   animation costs no JS and no property writes per frame, however many
+   elements move. Flat spec, ms durations, kind inferred:
+   `{ duration }` / `{ duration, bounce }` is a spring (the default kind;
+   springs carry velocity, so a retarget mid-flight stays continuous -
+   use them for anything interactive), `{ duration, curve }` is a tween
+   (`linear | ease | ease-in | ease-out | ease-in-out` or a cubic-bezier
+   array; tweens restart from the current value on retarget, CSS
+   semantics). Keys are property names plus `all` as catch-all; a string
+   is shorthand (`transition="300ms ease-out"`); `delay` holds each
+   write, `from` animates the first attach in (enter), `exit` animates
+   removal out before the node frees, `stagger` on a parent cascades its
+   children's enters/exits, and `onTransitionEnd` fires per settled
+   property. The initial value never animates without `from`; a write to
+   a property without a transition snaps, as always. A JS tween loop or
+   animation library pushing interpolated values through signals pays the
+   whole write path per element per frame - port it to this.
+2. Continuous effects (snow, particles, animated backgrounds) belong in a
+   fragment shader: createShaderTexture (from @solidrt/core/gpu) + `<texture
+   params={{ uTime }}>` (the shader declares `uniform float uTime;` itself -
+   the preamble declares only what the runtime fills). The whole effect then
+   costs one setProperty per frame - the uTime write - regardless of visual
+   complexity. Shader output
+   must be premultiplied alpha (white flakes are `vec4(vec3(a), a)`);
+   straight alpha (`vec4(1,1,1,a)`) composites as opaque white. A source that
+   starts with `#version 300 es` is compiled exactly as written - no preamble
+   is injected, though the built-in vertex stage still supplies `vUV` - so a
+   shader ported from elsewhere keeps its own uniform names without dropping
+   to compileShader/linkProgram. Params drive any uniform type: a number
+   fills a `float`/`int` scalar, a flat number array fills `vec2`/`vec3`/
+   `vec4` (2/3/4 numbers) or `mat4` (16, column-major), dispatched by the
+   shader's own declaration - a ported shader's `vec2 uCenter` or
+   `vec3 iResolution` needs no splitting into scalars. To combine several
+   GPU passes, stack `<texture>` elements and set `blendMode` (e.g. a base
+   pass plus an additive `blendMode="plus"` pass) rather than writing a
+   compositing shader. Within one pipeline draw, createPipelineTexture's
+   `blend: "add"` accumulates overlapping geometry additively (soft point
+   splats, glow) - pair it with `depthWrite: false` when depth-tested;
+   neither option implies the other. A pipeline's own vertex stage writes
+   into a y-down clip space: `gl_Position` y = -1 is the top row of the
+   target and +1 the bottom, so camera-up geometry must negate y (or fold
+   the flip into its projection) or it draws upside down. Sampling is a
+   create-time option on every texture: `{ filter: "nearest" }` for
+   hard-pixel upscaling (render a small target, display it big - the
+   retro/pixel-art path) and `{ wrap: "repeat" }` to tile outside 0..1 in
+   shaders; the defaults are linear and clamp, and the choice applies both
+   on screen and to shaders sampling the texture.
+3. Reduce setProperty calls wherever possible: one path string rebuilt per
+   frame beats N elements with N animated positions; a shader beats the path
+   string. get_stats' setPropsPerFrame is the counter to watch. Compiled JSX
+   attribute expressions diff before writing, so a per-frame expression that
+   returns an unchanged value costs no property write - setPropsPerFrame
+   counts values that actually changed, not expressions re-run.
+4. Never leave onFrame registered while nothing animates: a pending onFrame
+   is a standing frame request, so the runtime renders and presents every
+   vsync even when the callback body does nothing - an invisible 60fps GPU
+   burn that also drags the OS compositor along with it. Tweens and
+   springs need no pump at all - that is rule 1, and the runtime requests
+   frames only while tracks run. For genuinely procedural per-frame motion,
+   use a self-rechaining one-shot requestAnimationFrame that stops
+   re-requesting when its work list empties. (Registering onFrame outside a
+   component body also warns NO_OWNER_CLEANUP - it assumes a reactive owner.)
+5. repaintBoundary works like Flutter's: transforms and opacity on the
+   boundary node itself (or any ancestor) are hoisted out of the cache and
+   applied at composite time, so animating x/y/scale/rotate/opacity of a
+   boundary does NOT re-raster it (verified by A/B measurement - the damage
+   system classifies these as Transform and keeps the node's own cache).
+   What DOES invalidate the cache is any paint or content change inside the
+   subtree - colors, path data, text, a Show toggling - so drive animation
+   with transforms and keep the cached content itself static. Off a boundary,
+   `opacity` on a view is NOT cheap: it wraps the subtree in a compositing
+   layer (save_layer) for as long as it is below 1. To fade a single
+   primitive, put the alpha in its `color` (`rgba(...)`) - paint alpha is
+   free; reserve view `opacity` for fading a genuine group as a whole.
+   Placement rule for animation-heavy screens: a boundary around a node
+   that animates its own paint (a moving d-*, a changing color) is useless
+   - its interior is damaged every frame, so the cache never survives. The
+   win is a boundary around the static bulk NEXT TO the animators: the
+   frame then re-records only the moving nodes and replays the fenced
+   content as one cached draw, an order-of-magnitude cut when static
+   content dominates the node count. get_stats' nodesPainted shows exactly
+   what the paint walk still enters. The exception where a boundary on the
+   animator itself pays is transform/opacity animation of the boundary
+   node - the hoisting described above.
+6. "snapshot" boundaries pay first-frame texture allocation + raster:
+   creating many at once (dealing a board of 64 sprites) is a visible
+   one-frame hiccup - pool or pre-warm if that moment matters.
+7. Shading pixels the app already drew is a different mechanism from rule 2's
+   generated textures, and both forms are a `shader` prop taking a linked
+   program from compileShader/linkProgram (@solidrt/core/gpu), not a
+   createShaderTexture source. On `<window>`, `shader={{ program, params }}`
+   runs the finished frame through the program as the last step before it
+   reaches the screen: the frame binds as `uniform sampler2D uSource`,
+   `iResolution` fills by name, and `previous: true` retains the last frame as
+   `uPrevious` for motion echo or frame differencing. On a `<view>` the same
+   prop shades that subtree in place and REQUIRES repaintBoundary="snapshot"
+   (without it the shader is ignored with a warning); the pass sees only the
+   subtree's own pixels - grading, warping or dissolving the panel works,
+   anything needing what is behind it does not - and is split from content
+   invalidation, so a params-only change re-runs the pass against the cached
+   snapshot instead of re-rasterizing. A window shader's output is invisible
+   to get_snapshot and every other MCP tool; `bunx srt render` is the only
+   way to see it (see @solidrt/cli AGENTS.md).
+8. `flux:wasm` runs a pure interpreter (wasmi, no JIT), so temper browser
+   expectations - but do not write it off for compute. A genuinely numeric
+   kernel (typed-array math, tight inner loops, no host calls inside the
+   loop) compiled from a systems language can come out a real multiple
+   faster than the same loop in interpreted JavaScript, and when profiling
+   shows such a kernel is what the app is spending its time on, that
+   multiple is worth having: measure the JS loop, port the kernel, measure
+   again, keep whichever wins. What wasm does not do is speed up
+   render-path work (rules 1-3 are that leverage), and every host call
+   costs marshalling, so batch at the boundary - one call over a byte
+   buffer, not a call per element. It is also the way to ship one compiled
+   module across every target with no native toolchain, and it pairs with
+   an isolate when a call runs long enough to block.
+9. `flux:ffi` (dlopen of a native library) is a binding tool, not a
+   performance tool. It needs a shared library compiled per platform and
+   architecture and shipped under each target's packing rules (Android
+   loads only what arrives inside the APK as a lib*.so), so reaching for
+   it "to make something fast" buys a build-and-packaging problem on every
+   platform the app targets. Use it when the app must call a native
+   library that already exists and already ships for those targets; for
+   speed, everything above comes first.
+
+## Isolates: heavy work off the JS thread
+
+A long synchronous computation (a big parse, a simulation step, a blocking
+`flux:ffi`/`flux:wasm` call) freezes rendering and input for its duration.
+Move it into an isolate module: a file whose first statement is the
+`"use isolate"` directive runs in a second runtime on its own thread, and
+main calls its exports as async functions.
+
+```ts
+// src/worker.ts
+"use isolate"
+export function crunch(data: Uint8Array): number { /* ... */ }
+```
+
+```ts
+// src/index.tsx
+import { isolate } from "flux:isolate"
+import type * as Worker from "./worker"
+let worker = isolate<typeof Worker>("worker")   // id = path from src/, no extension
+let n = await worker.crunch(bytes)              // main keeps rendering meanwhile
+```
+
+The bundler builds each such module as its own bundle and ships it with the
+app (dev pushes and `srt pack` alike). Rules: main may only `import type`
+from an isolate module (a value import is a build error); arguments and
+results are copies (numbers, strings, byte buffers, arrays, plain objects -
+no functions, no class instances); the child has the non-gui `flux:*`
+modules only, so it never touches the render tree; module state persists
+between calls and each `isolate()` call is its own instance. An
+`async function*` export is a stream: `for await (let p of worker.progress())`
+pulls one item per step (progress, ticks, a subscription), `break` ends it in
+the isolate, and streams never block plain calls. Full contract:
+node_modules/@solidrt/flux-types/modules/isolate.d.ts.
+
+## Where GPU work stops being free
+
+"GPU work is nearly free" is a property of the hardware, not of the engine, and
+the spread is wide enough to design against rather than discover late. The same
+app - two point-cloud pipelines, 233,600 vertices, one params write each per
+onFrame, i.e. exactly what rule 2 recommends - measured 16.7 ms/frame (60 fps,
+vsync-locked) on both desktop and a mid-range 2020 tablet, and 120 ms/frame
+(8.3 fps) on a 2017 Android TV. Roughly 8x for identical work, with the tablet
+indistinguishable from desktop. Measure on a target device if it matters; do
+not infer it from the desktop number.
+
+- **On a tiled GPU the budget is primitive count, not pixels.** Every point or
+  triangle costs the tiler regardless of how few pixels it covers. On that TV,
+  frame time against total vertices with a trivial vertex shader: 20k -> 80 ms,
+  35k -> 100 ms, 100k -> 380 ms. Meanwhile `gl_PointSize = 3.0` - nine times
+  the fill - measured within one vsync of 1.0, and rendering into a
+  quarter-size target measured identical to full size. So for a heavy pass the
+  lever is fewer primitives; shrinking the target or the splat usually is not,
+  and coverage is far cheaper bought with point size than with more points.
+- **A device's compositor can set the frame budget outright**, in which case
+  none of the above moves. That TV never presents faster than every 80 ms -
+  four refresh periods blocked inside `eglSwapBuffers` - even for a near-empty
+  scene, so its ceiling is ~12 fps whatever you draw. Recognise it by a
+  content-independent floor: if a trivial scene and a heavy one present at
+  nearly the same rate, you are compositor-bound and tuning the scene is
+  wasted effort.
+- **Per-frame writes are gated on the raster thread, not on vsync**, so a pass
+  that costs more than a refresh period does not silently pile up. If
+  `rasterQueue` climbs across queries while fps drops the raster thread is
+  behind; if `fenceTimeoutsPerSec` (in get_stats' window block) is nonzero,
+  the GPU is over its pacing budget right now.
+
+Finding your own numbers: `get_stats` gives fps, frameMs, setPropsPerFrame,
+the window summary (worst frame, percentiles, GPU rates), rasterQueue and
+fenceTimeouts. When those disagree with what the screen is
+visibly doing, ground truth on Android is
+`adb shell dumpsys SurfaceFlinger --latency <layer>` for real present
+timestamps - engine-reported phase timings can each be honest and still not add
+up to the frame period, because work outside the frame call is not in them.

package/examples/README.md

@@ -47,8 +47,8 @@ for the element/prop model see `@solidrt/core/AGENTS.md`.
 - `window-shader.tsx` - the `shader` prop on `<window>`: the finished frame drawn through a raw-linked warp program before present, click to toggle between warp and identity.
 - `window-shader-history.tsx` - the window shader's frame history: `previous` binds last frame as uPrevious, drawn as a one-frame motion echo behind an orbiting square; click toggles the echo term.
 
-## Sound
-- `sound.tsx` - `createSound`: decode a clip once from bytes (here a binary import), replay cheaply; `overlap` stacking vs single-voice, `playing()` signal, release on unmount. Points to `createSoundStream` for long tracks streamed from a path.
+## Audio
+- `audio.tsx` - `createSound`: decode a clip once from bytes (here a binary import), replay cheaply; `overlap` stacking vs single-voice, `playing()` signal, release on unmount. `createPcmSound` for a synthesised clip from raw samples (a generated sine sweep). Points to `createSoundStream` for long tracks streamed from a path.
 
 ## Vector graphics
 - `parse-svg.tsx` - `parseSvg` turns a whole SVG *document string* (not HTML/JSX children) into plain draw data mapped to `<d-path>` inside a `viewBox`-fitted view; per-shape hover highlighting shows the payoff (exact-outline hit testing, recolor without re-parse), plus a `currentColor` icon recolored via the `color` option. This is how to use existing icon libraries (Lucide, Heroicons, etc.) - hand their SVG source to `parseSvg`.

package/examples/{sound.tsx → audio.tsx}

@@ -14,14 +14,32 @@
 // selection tick. playing() is a signal: true from play() until stop() (it
 // does not flip back when a clip ends naturally).
 //
+// Sounds you can compute need no bytes at all: createPcmSound takes raw
+// samples (here a 60 ms sine sweep in an Int16Array) and gives the same handle
+// - generate it, do not ship it. Same reactive ownership as createSound.
+//
 // For a long track (music, ambience) do not load bytes at all: pass a file
 // path to createSoundStream from the same module, which decodes from disk on
 // demand and stays off the heap. Same play()/stop()/playing() surface,
 // always single-voice.
 import { render } from "@solidrt/core"
-import { createSound } from "@solidrt/core/sound"
+import { createPcmSound, createSound } from "@solidrt/core/audio"
 import blipBytes from "./blip.wav" with { type: "binary" }
 
+const RATE = 44100
+// A short sweep from 880 Hz down to 440 Hz with a linear fade-out.
+function sweep(): Int16Array {
+  let n = Math.round(RATE * 0.06)
+  let out = new Int16Array(n)
+  let phase = 0
+  for (let i = 0; i < n; i++) {
+    let t = i / n
+    phase += (2 * Math.PI * (880 - 440 * t)) / RATE
+    out[i] = Math.round(Math.sin(phase) * (1 - t) * 0.6 * 32767)
+  }
+  return out
+}
+
 function Button(props: { label: string; onTap: () => void }) {
   return (
     <view onPointerDown={props.onTap} padding={12} clipRadius={8}>
@@ -34,13 +52,15 @@ function Button(props: { label: string; onTap: () => void }) {
 function App() {
   let blip = createSound(blipBytes, { gain: 0.8 })
   let tick = createSound(blipBytes, { overlap: false })
+  let synth = createPcmSound(sweep(), RATE)
 
   return (
     <window padding={20} gap={8} alignItems="flex-start">
       <Button label="Blip (tap fast to stack voices)" onTap={() => blip.play()} />
       <Button label="Tick (overlap: false, restarts)" onTap={() => tick.play()} />
-      <Button label="Stop" onTap={() => { blip.stop(); tick.stop() }} />
-      <text color="#888">{blip.playing() || tick.playing() ? "playing" : "silent"}</text>
+      <Button label="Sweep (createPcmSound, generated)" onTap={() => synth.play()} />
+      <Button label="Stop" onTap={() => { blip.stop(); tick.stop(); synth.stop() }} />
+      <text color="#888">{blip.playing() || tick.playing() || synth.playing() ? "playing" : "silent"}</text>
     </window>
   )
 }

package/examples/gpu-sprites.tsx

@@ -0,0 +1,102 @@
+// The zero-copy per-frame geometry path: instanced quads whose records are
+// rewritten every frame through a buffer write lease. beginBufferWrite hands
+// back a Float32Array over runtime-owned memory (contents unspecified - fill
+// everything you publish), the frame callback writes every live record into
+// it, and endBufferWrite publishes by MOVING the block to the raster thread:
+// no data copy anywhere on the CPU path, and no per-sprite property writes.
+// Compare gpu-instancing.tsx, where the records are static and only the draw
+// range changes; here the records themselves are the animation.
+//
+// The buffer is created from a byte LENGTH (zeroed storage) - the natural
+// create when every byte arrives through the lease. Publishing a prefix and
+// setDraw({ instanceCount }) keep buffer capacity and live population
+// independent: reserve the max up front, publish what exists this frame.
+import { render, onFrame } from "@solidrt/core"
+import { beginBufferWrite, createBuffer, createPipelineTexture, endBufferWrite, glsl, setDraw } from "@solidrt/core/gpu"
+
+const MAX_SPRITES = 2000
+// floats per record: center vec2, half-size f32, tint vec3.
+const RECORD = 6
+
+let VERTEX = glsl`
+  in vec2 aPos;
+  in vec2 iCenter;
+  in float iSize;
+  in vec3 iTint;
+  out vec3 vTint;
+
+  void main() {
+    gl_Position = vec4(iCenter + aPos * iSize, 0.0, 1.0);
+    vTint = iTint;
+  }
+`
+
+let FRAGMENT = glsl`
+  in vec3 vTint;
+
+  void main() {
+    fragColor = vec4(vTint, 1.0);
+  }
+`
+
+// Simulation state lives in plain arrays; the instance buffer holds only
+// this frame's published snapshot of it.
+let x = new Float32Array(MAX_SPRITES)
+let y = new Float32Array(MAX_SPRITES)
+let vx = new Float32Array(MAX_SPRITES)
+let vy = new Float32Array(MAX_SPRITES)
+for (let i = 0; i < MAX_SPRITES; i++) {
+  x[i] = Math.random() * 1.9 - 0.95
+  y[i] = Math.random() * 1.9 - 0.95
+  vx[i] = (Math.random() * 2 - 1) * 0.01
+  vy[i] = (Math.random() * 2 - 1) * 0.01
+}
+
+function App() {
+  // One unit quad (triangle strip), reused by every instance.
+  let quad = createBuffer(new Float32Array([-0.5, -0.5, 0.5, -0.5, -0.5, 0.5, 0.5, 0.5]), { label: "sprite-quad" })
+  let records = createBuffer(MAX_SPRITES * RECORD * 4, { label: "sprite-records" })
+  let id = createPipelineTexture(VERTEX, FRAGMENT, 720, 720, null, {
+    label: "sprites",
+    topology: "triangle-strip",
+    vertexCount: 4,
+    attributes: [{ name: "aPos", format: "vec2" }],
+    buffer: quad,
+    instanceAttributes: [
+      { name: "iCenter", format: "vec2" },
+      { name: "iSize", format: "f32" },
+      { name: "iTint", format: "vec3" },
+    ],
+    instanceBuffer: records,
+    instanceCount: MAX_SPRITES,
+    clearColor: [0.03, 0.03, 0.06, 1],
+  })
+
+  onFrame(() => {
+    let out = beginBufferWrite(records)
+    for (let i = 0; i < MAX_SPRITES; i++) {
+      let nx = x[i]! + vx[i]!
+      let ny = y[i]! + vy[i]!
+      if (nx < -0.95 || nx > 0.95) vx[i] = -vx[i]!
+      else x[i] = nx
+      if (ny < -0.95 || ny > 0.95) vy[i] = -vy[i]!
+      else y[i] = ny
+      let at = i * RECORD
+      out[at] = x[i]!
+      out[at + 1] = y[i]!
+      out[at + 2] = 0.01 + 0.008 * (i % 5)
+      out[at + 3] = 0.5 + 0.5 * Math.cos(i * 0.11)
+      out[at + 4] = 0.5 + 0.5 * Math.cos(i * 0.13 + 2.1)
+      out[at + 5] = 0.5 + 0.5 * Math.cos(i * 0.17 + 4.2)
+    }
+    endBufferWrite(records)
+  })
+
+  return (
+    <window alignItems="center" justifyContent="center">
+      <texture src={id} width={480} height={480} />
+    </window>
+  )
+}
+
+render(() => <App />)

package/jsx-runtime.d.ts

@@ -7,6 +7,7 @@ import type {
   ViewProps,
   ViewOwnProps,
   TextProps,
+  SpanProps,
   TextureProps,
   LayoutProps,
   PositionProps,
@@ -14,6 +15,7 @@ import type {
   OvalGeometryProps,
   TextGeometryProps,
   LineGeometryProps,
+  TransitionProps,
   Element as CoreElement,
   ElementChildrenAttribute as CoreElementChildrenAttribute
 } from "./src/types"
@@ -40,19 +42,22 @@ export namespace JSX {
   // layout box; d-* forms compose the paint-space geometry props instead.
   interface IntrinsicElements {
     window: WindowProps & ElementRef
-    view: ViewProps & ElementRef
-    text: TextProps & LayoutProps & ElementRef
-    rect: RectProps & LayoutProps & ElementRef
-    oval: OvalProps & LayoutProps & ElementRef
-    line: LineProps & LayoutProps & ElementRef
-    path: PathProps & LayoutProps & ElementRef
-    texture: TextureProps & LayoutProps & ElementRef
-    "d-view": ViewOwnProps & ElementRef
-    "d-rect": RectProps & GeometryProps & ElementRef
-    "d-oval": OvalProps & OvalGeometryProps & ElementRef
-    "d-line": LineProps & LineGeometryProps & ElementRef
-    "d-path": PathProps & PositionProps & ElementRef
-    "d-texture": TextureProps & GeometryProps & ElementRef
-    "d-text": TextProps & TextGeometryProps & ElementRef
+    view: ViewProps & TransitionProps & ElementRef
+    text: TextProps & LayoutProps & TransitionProps & ElementRef
+    rect: RectProps & LayoutProps & TransitionProps & ElementRef
+    oval: OvalProps & LayoutProps & TransitionProps & ElementRef
+    line: LineProps & LayoutProps & TransitionProps & ElementRef
+    path: PathProps & LayoutProps & TransitionProps & ElementRef
+    texture: TextureProps & LayoutProps & TransitionProps & ElementRef
+    "d-view": ViewOwnProps & TransitionProps & ElementRef
+    "d-rect": RectProps & GeometryProps & TransitionProps & ElementRef
+    "d-oval": OvalProps & OvalGeometryProps & TransitionProps & ElementRef
+    "d-line": LineProps & LineGeometryProps & TransitionProps & ElementRef
+    "d-path": PathProps & PositionProps & TransitionProps & ElementRef
+    "d-texture": TextureProps & GeometryProps & TransitionProps & ElementRef
+    "d-text": TextProps & TextGeometryProps & TransitionProps & ElementRef
+    // A styled run inside <text>/<d-text>; never has a layout box, so there is
+    // no d- form.
+    span: SpanProps & ElementRef
   }
 }

package/package.json

@@ -1,17 +1,20 @@
 {
   "name": "@solidrt/core",
-  "version": "0.0.49",
+  "version": "0.0.51",
   "license": "MIT",
+  "funding": "https://github.com/sponsors/wellawaretech",
   "author": "Antoine van Wel",
   "type": "module",
   "main": "src/index.ts",
   "exports": {
     ".": "./src/index.ts",
     "./camera": "./src/camera.ts",
+    "./color": "./src/color.ts",
+    "./data": "./src/data.ts",
     "./gpu": "./src/gpu.ts",
     "./image": "./src/image.ts",
+    "./audio": "./src/audio.ts",
     "./microphone": "./src/microphone.ts",
-    "./sound": "./src/sound.ts",
     "./speech-recognition": "./src/speech-recognition.ts",
     "./text-input": "./src/text-input.ts",
     "./jsx-runtime": "./jsx-runtime.d.ts",
@@ -21,13 +24,11 @@
     "src/",
     "examples/",
     "jsx-runtime.d.ts",
+    "agents/",
     "AGENTS.md"
   ],
-  "dependencies": {
-    "colord": "^2.9.3"
-  },
   "devDependencies": {
-    "@solidrt/flux-types": "0.0.49"
+    "@solidrt/flux-types": "0.0.51"
   },
   "peerDependencies": {
     "@solidjs/signals": "2.0.0-rc.0",