Fragment Color | Blog

v0.11.0: all planned languages release

Mon, 04 May 2026 00:00:00 GMT

v0.11.0 completes the set of languages FragmentColor was designed for: Rust, JavaScript, Python, Swift, and Kotlin. The same Renderer, Shader, Pass, and Texture types now run natively on iOS and Android, at parity with the desktop and web bindings.

The other half of the release is a substantial pass over the API itself. The texture API now has a single, unified shape; Shader gained composition primitives that set up the upcoming registry; KTX2 and wider source-format coverage land for production asset pipelines; texture decoding moves off the renderer thread; method naming got a top-to-bottom audit; and the underlying wgpu/naga stack moves from 27 to 29.

What mobile looks like

On iOS (Swift):

import FragmentColor

let renderer = Renderer()
let target = renderer.createTarget(layer: metalLayer)   // your CAMetalLayer
let shader = Shader(source: wgslSource)
try renderer.render(shader, target)

On Android (Kotlin):

import org.fragmentcolor.*

val renderer = Renderer()
val target = renderer.createTarget(surface)             // android.view.Surface
val shader = Shader.new(wgslSource)
renderer.render(shader, target)

Bindings are generated with uniffi, so the type names match the Rust core and the concepts carry over verbatim as you move between platforms.

Distribution

Swift ships as a Swift Package. Add https://github.com/vista-art/fragmentcolor as a package dependency (from: "0.11.0"); SPM pulls the matching fragmentcolor.xcframework.zip from the GitHub release and verifies it against a pinned SHA-256.
Kotlin ships as an .aar attached to the GitHub release for 0.11.x. Maven Central publishing is in progress.

Every PR that touches mobile code rebuilds the xcframework and runs a headless smoke test on an iPhone simulator. The Android equivalent boots a KVM-accelerated emulator and runs connectedAndroidTest against the Kotlin bindings.

Five-language healthchecks

Every public method has a Rust example in docs/api/. The build script transpiles each example into JavaScript, Python, Swift, and Kotlin, then aggregates the per-language outputs into compile-only test files that ride along with each platform’s existing healthcheck.

./healthcheck now exercises ~88 examples on every binding. JavaScript and Python execute them through Playwright and a headless wheel; Swift and Kotlin compile them as part of xcodebuild and connectedAndroidTest. The Rust files in docs/api/ are the source of truth, so a doctest regression on Rust is the only thing that can let an inconsistency through.

A unified texture API

Texture creation in v0.10.x had three transports (TextureSpec, StorageTextureInput, PrepareSpec) and around nine entry points (create_texture_with_size, create_texture_with_format, create_texture_prepared, create_storage_texture_with_data, …). v0.11.0 collapses the surface to three entry points that all accept the same input shapes:

let tex   = renderer.create_texture("image.png").await?;              // file path
let tex   = renderer.create_texture(png_bytes).await?;                // encoded bytes
let tex   = renderer.create_texture((rgba, [w, h])).await?;           // raw pixels
let store = renderer.create_storage_texture(([256, 256], TextureFormat::Rgba16Float)).await?;
let chain = TextureMipChain::prepare((png_bytes, TextureFormat::Rgba8UnormSrgb))?;
let tex   = renderer.create_texture(chain).await?;                    // pre-baked

The same call shapes work in JavaScript, Python, Swift, and Kotlin, with each binding using its native syntax for the tuple/options.

TextureMipChain is a new public type on every binding. It builds the CPU mipmap chain off-thread from encoded image bytes or raw pixels, so a tile-cache loader on its own worker thread can fold the resize pass into the same hop and hand the renderer a finished chain. In one consumer app, tile uploads dropped from 30-50 ms of GPU-thread work to a single queue.write_texture call.

Renderer::create_texture no longer blocks the renderer thread on native targets. Decoding, the Triangle-filter mipmap chain, and the per-level texture writes run on a named background worker; the public API stays await-shaped, but the caller’s GPU and event-loop threads are no longer pinned for the duration. On the web, the work runs inline because the underlying GPU types can’t be moved across threads. Drop heavy decode into a Web Worker yourself if you need parallelism there.

Shader composition

Shader::new now classifies its input by shape: a single string is raw WGSL/GLSL source, a registry slug like "sdf2d/circle", an https:// URL, or a local path. An array mixing any of those is resolved (fetched, read, looked up), deduped by source hash, and concatenated in order before validation.

let shader = Shader::new(["sdf2d/circle", "noise/simplex2", main_src])?;
let shader = Shader::fetch("https://fragmentcolor.org/shaders/sdf2d/circle.wgsl").await?;
let shader = Shader::new("sdf2d/circle")?;  // resolves through the registry

Shader::fetch is the async path; it classifies input the same way as new and is available on every binding (await Shader.fetch(...) in JS and Python, try await Shader.fetch(...) in Swift, Shader.fetch(...) in Kotlin). Override the slug base URL with Shader::set_registry(base_url).

This is the on-ramp to the curated registry that lands in v0.14.x. The composition machinery (parts, dedup, slug-to-URL resolution) is in place today; the shader collection at shaders.fragmentcolor.org fills in over the 0.11.x to 0.14.x window. GLSL is supported as a single part; mixing GLSL with WGSL or with other parts is rejected.

Production texture loading: KTX2 and wider formats

KTX2 container support. TextureInput gained three KTX2 variants (Ktx2Bytes, Ktx2Path, Ktx2Url) that go through the regular Renderer::create_texture entry point alongside JPEG and PNG. KTX2 inputs trust the file’s declared format and pre-baked mip chain; TextureOptions.format and TextureOptions.mipmaps are deliberately ignored for them, because re-running either step would round-trip through a worse approximation.

Format coverage:

Uncompressed RGBA8, RGBA16F, and the R / G / RG / RGBA 8- and 16-bit families.
BC1-BC7.
ETC2 RGB, RGBA, and RGB-A1.
ASTC 4×4 and 8×8.

The mapping from Vulkan VkFormat values follows the KTX2 spec. Compression features are requested opportunistically at device creation, so adapters without a given feature still get a working device. A KTX2 load that targets a format the GPU can’t sample fails at upload with a clear error rather than at sample time.

Wider source-image coverage. Source-image decoding now picks the right pixel buffer for the target format: R8Unorm via to_luma8, R16Unorm via to_luma16, Rg8Unorm via to_luma_alpha8, Rg16Unorm via to_luma_alpha16, and Rgba16Unorm via to_rgba16. The previous code path went through to_rgba8 for everything, silently truncating 16-bit-per-channel input. Height maps and mask buffers loaded through Renderer::create_texture(path) were producing 8-bit output without a warning.

Mipmaps and trilinear filtering by default. Renderer::create_texture now generates a full mipmap chain at upload (Triangle filter via image::imageops::resize), and the default linear sampler picks mipmap_filter: Linear when smooth: true. The moving moiré you’d see when zooming out on a textured quad with high-frequency detail (canvas weave in painted JPEGs is the canonical case) is gone. Opt out with TextureOptions { mipmaps: false, .. } for textures you’ll only ever sample at 1:1.

Compute API improvements

Two direct additions:

// Seed a storage texture from a CPU blob in one call.
// (size, format) allocates empty; (size, format, bytes) seeds from a buffer.
let tex = renderer
    .create_storage_texture(([256, 256], TextureFormat::Rgba16Float, bytes))
    .await?;

// Read back the contents of any registered texture in its native format.
let pixels = renderer.read_texture(*tex.id()).await?;

Readbacks (Renderer::read_texture, Texture::get_image, TextureTarget::get_image) poll the device internally before mapping the staging buffer, so a render → readback sequence is deterministic without any explicit synchronization on the caller’s side.

TextureFormat::Rgba16Float joins the supported set: 16-bit float per channel, filterable, and storage-writable without a feature opt-in. The right pick for iterative simulations where 8-bit precision isn’t enough and 32-bit is overkill.

Compute correctness fixes

Three correctness fixes also land:

Sampled textures and samplers now include ShaderStages::COMPUTE in their bind-group layouts, matching uniforms and read-only storage buffers. textureSample from a compute shader works directly, without the workaround of declaring sources as texture_storage_2d<..., read>.
texture_storage_2d<..., read_write> maps to combined LOAD | STORE access. textureStore against a read_write texture passes validation, and ping-pong pairs that can collapse to a single texture do so.
Texture::get_image advances the wgpu event loop on native (device.poll(Wait)), so the readback callback always completes.

An Apple Silicon compute barrier

Apple Silicon needs a submission boundary to flush tile-based storage writes before a later compute pass can sample them through texture_2d<f32> / textureLoad. Without the boundary, the sample silently returns zeros.

v0.11.0 detects the platform and inserts the boundary automatically between sequential compute passes on macOS and iOS. There’s nothing to opt into; non-Apple targets are unaffected.

The same class of TBDR bug also affects compute → render sequences inside one command buffer; the auto-split for that case is queued for v0.11.x. Until it lands, the workaround is to issue two separate Renderer::render calls. Each one ends with its own submission, which is enough of a boundary in practice.

`R16Unorm` (and the 16-bit norm family) now works on every adapter that advertises it

A bug surfaced through a consumer’s shader path: an R16Unorm TextureMipChain that round-tripped cleanly through prepare → device.create_texture produced a silently-invalid texture on Apple Silicon, then exploded on the first create_view() with an InvalidResource cascade that drowned consumer logs 60 times per second. Same for Rg16Unorm, Rgba16Unorm, and the three *Snorm variants.

Three layered fixes, so the failure mode no longer reaches the user:

The adapter feature probe opportunistically requests TEXTURE_FORMAT_16BIT_NORM and FLOAT32_FILTERABLE on every adapter that advertises them.
A TextureError::UnsupportedFormatForUsage guard fails fast at the API boundary on adapters that don’t.
A new RenderContext::validate(label, op) helper folds bind-group and view creation through wgpu’s validation scope, so any remaining validation failures come back as one programmatic error instead of a four-tier cascade.

API naming pass

A cross-cutting audit. The rule: one verb, or at most three words. Suffixes only when they disambiguate genuinely distinct inputs (from_file vs from_bytes). No _async, _kind, _object, _with_X, or _checked variants. Internal helpers paid the same tax.

Consumer-visible changes (Rust):

TextureTarget::get_image_async → removed. Target::get_image is now async fn on the trait, mirroring Texture::get_image().
Pass::add_mesh_to_shader(mesh, shader) → removed. The body was shader.add_mesh(mesh)?; use shader.add_mesh(mesh) directly.
App::on_event_kind / on_window_event_kind / on_device_event_kind → drop _kind. The catch-all variants on_event(f) (no kind arg) were removed entirely; kind-filtered registration is the only way.
set_color_target_id(id) → set_color_target(id). The arg name carries the type.
create_external_texture_from_native / create_external_texture (free functions) → ExternalTextureHandle::from_native / from_video (associated functions).
create_texture_with_size / _with_format / _with / _prepared → create_texture(input). Same shape for create_storage_texture and TextureMipChain::prepare.

Sync/async pair unification borrows the blocking submodule convention from reqwest::blocking: shader::input::resolve_async → resolve (top-level, async); the previous sync resolve moves to blocking::resolve.

`Frame` is gone

Frame was a thin collector over Pass objects. After the dependency-graph refactor a few releases ago, it held no capability that Pass::require() (DAG) or an iterable of Pass (sequential rendering) didn’t already cover. Renderer::render already accepts a single pass, a Vec<Pass>, or a slice of either, so every Frame use case transliterates directly. Each public symbol multiplies across five language bindings, and shrinking that surface is worth the transliteration cost.

// Before
let mut frame = Frame::new();
frame.add_pass(&a);
frame.add_pass(&b);
renderer.render(&frame, &target);

// After
renderer.render(&vec![a, b], &target);

The same migration applies in JS, Python, Swift, and Kotlin: pass the array directly to renderer.render.

Upgrading wgpu 27 → 29

The internal wgpu/naga stack moves from 27.0.1 to 29.0.1; the public FragmentColor API is unchanged. The upgrade involved a sizeable adapter pass internally: SurfaceError was removed, push constants were renamed to “immediates”, depth_write_enabled became Option-typed, bind-group-layout slots became gap-tolerant, and the instance descriptor changed shape.

The one user-visible WGSL change comes from that rename: wgpu 29 accepts var<immediate> where 27 accepted var<push_constant>. Update any shader that still uses the old spelling; naga’s WGSL front end no longer recognizes it.

Roadmap

Next up beyond 0.11.0:

Example iOS and Android apps under platforms/swift/examples/ and platforms/kotlin/examples/.
Maven Central publishing for the Kotlin AAR.
Swift Package Index registration.
Expanded mobile healthchecks (textures, immediates, full render loops).
A revamped RenderPass API that gives you more of wgpu::RenderPass with sensible defaults.
A compute → render auto-split, covering the second half of the Apple TBDR hazard.
Custom blending.
The first end-to-end external_texture implementation. The API surface is in place on every binding; the per-platform plumbing is the gap.
Snapshot testing and hot reload.

v0.12.0 is the asset-pipeline cut: KTX2 streaming, glTF, Basis Universal, post-FX templates. v0.14.0 is the live-coding REPL plus WGSL composition with a hosted registry. v1.0 is API stability.

Install it with:

# Rust
cargo add fragmentcolor

# JavaScript
npm install fragmentcolor

# Python
pip install fragmentcolor rendercanvas glfw

# Swift (Package.swift)
.package(url: "https://github.com/vista-art/fragmentcolor", from: "0.11.0")

# Kotlin (download fragmentcolor-0.11.0.aar from the GitHub Release)

Release notes: GitHub v0.11.0.

Rafael

v0.10.11: direct texture writes and external video on the web

Mon, 30 Mar 2026 00:00:00 GMT

v0.10.11 introduces direct writes to textures from CPU memory, zero-copy HTML video textures on the web, and updated Python integration with RenderCanvas 2.0. It is the final desktop and web release before mobile.

Writing to textures

Bitmap and pixel data can now be written directly into a texture, without a shader pass:

let texture = renderer.create_texture_with_size([512, 512]);
texture.write(&renderer, &pixel_bytes)?;

The API also includes Texture::write_with for partial updates with explicit origin, size, and bytes-per-row, and Renderer::update_texture / update_texture_with on the renderer side. Renderer::unregister_texture removes a texture from the registry on demand.

Sampling HTML `<video>` on the web

The web binding gains a zero-copy path from the browser’s video decoder via WebGPU’s texture_external:

const video = document.querySelector('video');
const texture = await renderer.createExternalTextureFromHtmlVideo(video);
shader.set('frame', texture);

This avoids the extra drawImage(video, …) step. Chromium has full support; Safari’s WebGPU has the binding too, though its API changes from time to time. Please open an issue if something behaves unexpectedly.

RenderCanvas 2.0 compatibility

Renderer::create_target reads screen-present info directly from RenderCanvas and builds the surface from that, replacing the previous custom context name. Pinning an older RenderCanvas is no longer necessary.

Per-language doc overrides

The system that generates JS and Python examples from Rust doc-strings supports per-language override snippets for cases where a direct translation reads awkwardly. The texture-write pages are the immediate use case: &[u8] in Rust, Uint8Array in JS, and bytes in Python all want slightly different framing.

Mobile is next. v0.11.0 is in development.

Release notes: GitHub v0.10.11.

Rafael

v0.10.10: long-lived WASM sessions

Tue, 21 Oct 2025 00:00:00 GMT

v0.10.10 improves the stability of the WASM bindings during long-running browser sessions. When the ArrayBuffer detaches mid-session, the binding switches to a live view of wasm.memory.buffer and continues operating.

This release matters most for long-lived browser surfaces such as kiosks, data-viz dashboards, and generative-art screensavers, where a tab can stay open for hours or days.

A few smaller items also land:

TextureInput on the JS bridge treats a zero-byte-length ArrayBuffer as detached or empty and returns an empty byte vector. This covers the case where a texture was loaded, the page sat idle, and memory then moved.
ImageData extraction uses the native Clamped<Vec<u8>> path and removes an extra copy_to step.
The ShaderHero component drops its per-frame debug instrumentation.

The public API is unchanged.

Release notes: GitHub v0.10.10.

Rafael

v0.10.9: stable type identity through minified builds

Fri, 17 Oct 2025 00:00:00 GMT

v0.10.9 ships a same-day follow-up to v0.10.8 for production builds that go through a minifier. It applies to anyone shipping FragmentColor through Terser or a similar bundler that rewrites class names.

The JavaScript bindings previously used class names as identity tokens (for example, to tell a Shader apart from a Texture). After minification, those names collapsed to single letters, and the identity check appeared as “Invalid target type” from Renderer.render().

v0.10.9 introduces stable string brands via impl_fc_kind!(TypeName, "TypeName") for every public type. The brand is written into the type at compile time and survives any minification pass.

Release notes: GitHub v0.10.9.

Rafael

v0.10.8: non-blocking uniforms, structured errors, and a new gallery

Thu, 16 Oct 2025 00:00:00 GMT

v0.10.8 lands three focused improvements informed by real-world use of the library, plus a refreshed visual front for the website.

Non-blocking `shader.set()`

Uniform updates queue a last-wins write that the renderer flushes right before binding, without taking a lock on the render thread. Per-frame updates from worker threads are now safe at the API level. Read methods still return ShaderError::Busy when another consumer holds the lock; writes always succeed.

Structured error variants

RendererError now includes MsaaViewMissing and DepthSampleCountMismatch. InitializationError includes AdapterNotSet. Callers can match on these as enum variants and design recovery paths around them.

A live shader demo

The homepage gets a ShaderHero component that runs an interactive shader at the top of the page. The component is the basis for a future gallery of works and serves as a continuous visual check of support across browsers.

Smaller things

WASM memory is pre-grown by 64 MiB at initialization, eliminating a class of mid-frame memory.grow stalls during the first few frames.
Pass infers its kind (render vs compute) from the first attached shader; the kind no longer has to be set explicitly.
The npm package ships branded JS prototypes, so instanceof checks survive minification. (Details in v0.10.9 below.)

Full changelog: GitHub v0.10.8.

Rafael

v0.10.7: feature parity across Rust, JavaScript, and Python

Sun, 05 Oct 2025 00:00:00 GMT

v0.10.7 covers desktop and web, and makes feature parity across Rust, JavaScript, and Python an enforced build requirement. v0.11 is reserved for the upcoming iOS and Android releases.

Enforced feature parity

Every public object is documented in docs/api, every doc has an ## Example section, and the build refuses to compile if a method is missing in any binding. The JavaScript and Python examples on this site are extracted from the same healthcheck scripts that run in CI on every push.

Textures and samplers are part of the core API

Textures load from bytes, paths, or URLs:

from fragmentcolor import Renderer, Shader

renderer = Renderer()
texture = renderer.create_texture("https://fragmentcolor.org/images/logo.png")

shader = Shader.new("...your shader...")
shader.set("image", texture)
shader.set("sampler", {"filter": "linear"})

Sample counts give you MSAA with automatic resolve. Storage textures support shader-side writes. Depth textures end up in the right layout because the renderer reads your shader’s binding metadata directly.

Meshes and multi-pass without the extra setup

Shader.add_mesh() and Pass.add_mesh_to_shader() cover vertex-layout configuration. The library inspects your shader’s @location inputs and refuses to attach a mesh that doesn’t fit. Multiple meshes per pass work, instancing works, and pipelines are cached by (shader, format, sample_count), so reusing the same shader across passes is cheap.

A new Frame object combines passes into a render graph (for example, “blur-x after scene, blur-y after blur-x”), with explicit require() edges that set the order.

One interface for everything you upload to a GPU

Uniforms, uniform arrays, storage buffers, storage buffer arrays, vertex buffers, index buffers, textures, storage textures, samplers, push constants. All of them go through shader.set("path.to.field", value), and the layout is inferred from your WGSL. Push constants fall back to a uniform buffer on targets that don’t support them.

Offscreen, headless, and CI-friendly

Rendering to a TextureTarget on any platform without a window is the documented path for headless tests. Useful if you want to snapshot-test a shader, or run generative art from a cron job.

If you want to try this:

# Rust
cargo add fragmentcolor

# JavaScript
npm install fragmentcolor

# Python
pip install fragmentcolor rendercanvas glfw

Full changelog: GitHub v0.10.7.

Start here: /welcome · /api · GitHub

Rafael

v0.10.5: First Python Release

Tue, 18 Mar 2025 00:00:00 GMT

v0.10.5 is the first FragmentColor release published to PyPI:

pip install fragmentcolor rendercanvas glfw

It is also the first release with an automated publishing process. Each of the patches in-between focused on a specific area:

v0.10.0-2: Library full rewrite, Shader object, first public release with the FragmentColor name.
v0.10.3: Moved the crate to Rust’s 2024 edition.
v0.10.4: Corrected a wheel import and completed the Pass / Frame API.
v0.10.5: Added the automated system that builds and publishes wheels for every desktop OS.

Release notes: GitHub v0.10.5.

I plan to publish it on npm on v0.10.6.

Rafael

v0.10.0: The Shader Object

Thu, 15 Feb 2024 00:00:00 GMT

This is the first release of FragmentColor.

FragmentColor is a universal GPU abstraction layer where you can simply write some WGSL or GLSL code, forget about pipeline setup, set uniforms by key-value, and it will render on every device in existence. That’s it.

This version is a full rewrite of the original PLRender engine from Pupil Labs, removing every module and keeping only three simple objects: the Shader, the Renderer, and the Target.

The central idea behind FragmentColor is runtime shader reflection. The shader code dictates the structures around it, and there is no need for you to think about buffer layouts and manual pipeline setup; you can just set your uniforms with the dot notation using the same name you declared in the shader itself:

let shader = Shader::new("shader source defining my_uniform");
shader.set("my_uniform", 0.5);
renderer.render(shader);

Feel free to read the docs for more details.

Install it on your favorite platform with:

cargo add fragmentcolor
npm install fragmentcolor
pip install fragmentcolor

Design Goals

FragmentColor aims to be the simplest GPU abstraction API in existence: being both simpler and more powerful than OpenGL. It builds on top of wgpu and abstracts away all the low-level boilerplate.

The core is minimalist on purpose. Only a few basic types (Shader, Pass, Texture, Renderer, Target, Vertex, and Mesh) can combine into anything you want to build or quickly prototype.

We’re also keeping up with wgpu and naga as they evolve, the WebGPU standards, and the WASM ecosystem. Every time there is a new API change or new upstream capability, we aim to implement it as quickly as possible and make the abstraction around it automated and minimal.

Credits / Acknowledgments

The Renderer API draws heavily from pygfx, a beautiful Python rendering engine that aims at a higher level than us. It is closer to Three.js for Python, with its own scene graph and renderable objects. FragmentColor uses pygfx’s RenderCanvas abstraction for the Python render surface.
The Shader-centric design came from Pupil Labs, as stated in our origin story.
Some of the GPU optimization techniques were inspired by Ruffle Flash Player engine.
Although most of the old code did not survive the full refactor, I owe most of my learning to kwark’s (the wgpu contributor) and his minimalistic prototype engine Baryon.
And, of course, nobody starts their wgpu journey without passing through the fantastic Learn Wgpu series by Ben Hansen.

Rafael

Where it all started

Fri, 15 Sep 2023 00:00:00 GMT

FragmentColor was first written inside Pupil Labs, an eye-tracking company from Berlin.

It was originally called PLRender, an attempt at an in-house engine for bridging the gap between JavaScript and Python, and my early attempts at building with wgpu, which was at version 0.17 at the time.

PLRender’s initial exploratory design was driven by a “we’ll need everything eventually” motivation: it had a scene graph, an ECS, reflection-based components, a few rendering primitives, collision detection, and (added later as an afterthought) a generic Shader object that could take arbitrary GLSL input.

The Shader object turned out to be the only piece we actually needed. That observation is what eventually became the v0.10.0 version: a full hard-reset rewrite that removed EVERYTHING from the library but the Shader object.

I’m grateful to Pupil Labs for generously releasing the code under the MIT license, and, in particular, Moritz, who asked the right question at the right time.

Rafael

Fragment Color | Blog

v0.11.0: all planned languages release

What mobile looks like

Distribution

Five-language healthchecks

A unified texture API

Shader composition

Production texture loading: KTX2 and wider formats

Compute API improvements

Compute correctness fixes

An Apple Silicon compute barrier

R16Unorm (and the 16-bit norm family) now works on every adapter that advertises it

API naming pass

Frame is gone

Upgrading wgpu 27 → 29

Roadmap

v0.10.11: direct texture writes and external video on the web

Writing to textures

Sampling HTML <video> on the web

RenderCanvas 2.0 compatibility

Per-language doc overrides

v0.10.10: long-lived WASM sessions

v0.10.9: stable type identity through minified builds

v0.10.8: non-blocking uniforms, structured errors, and a new gallery

Non-blocking shader.set()

Structured error variants

A live shader demo

Smaller things

v0.10.7: feature parity across Rust, JavaScript, and Python

Enforced feature parity

Textures and samplers are part of the core API

Meshes and multi-pass without the extra setup

One interface for everything you upload to a GPU

Offscreen, headless, and CI-friendly

v0.10.5: First Python Release

v0.10.0: The Shader Object

Design Goals

Credits / Acknowledgments

Where it all started

`R16Unorm` (and the 16-bit norm family) now works on every adapter that advertises it

`Frame` is gone

Sampling HTML `<video>` on the web

Non-blocking `shader.set()`