Developer documentation · July 2026 baseline

Three technical paths.
One visible learning system.
Many creative directions.

The first sections get a new developer running quickly. Later sections explain render ownership, media flow, GPU resources, state recovery, modernization lessons, and how the completed baselines inform Scheng and future standalone instruments.

⌕

Search setup, architecture, inputs, examples, and troubleshooting.

No sections match that search.

Layer 0 · Read this first

What Junkpile is #

Junkpile is a developer library of small, inspectable desktop applications for creative graphics and live media. Each project isolates one architecture so it can be run, traced, modified, packaged, and reused without inheriting a hidden monolith.

Tauri v1 WebView

Accessible browser rendering and native bridges using Tauri 1.

Tauri v2 WebView

Modern capabilities, window APIs, file workflows, and WebGL applications.

GPU

Native wgpu

Rust-owned GPU surfaces, WGSL, compute, 3D, media bridges, and export.

Completed baselineAll three collections contain Examples 00–25. The early v1 and v2 projects were modernized after the expansion so the complete library shares current interface, diagnostics, packaging, and documentation standards.

Standalone projects documented

Primary workflows runtime-tested

WebView and native GPU paths covered

Cross-platform validation ongoing

Layer 1 · Fast path

Run an example #

Install Rust, Node.js/npm, and Tauri prerequisites. Native-wgpu projects also need a functioning Metal, Vulkan, or Direct3D 12 backend.
Choose one project directory. Each project is independent; choose only the one you want to run or study.
Use its local scripts. Run npm install, then npm run dev. This selects the correct Tauri CLI major.
Confirm the documented baseline. Check the visual, telemetry, input, reset, fullscreen, and error states before editing.
Build the standalone app. Run npm run build. On macOS, bundles are normally written beneath src-tauri/target/release/bundle.

Per-example workflow

cd <collection>/<example-folder>
npm install
npm run dev
npm run build

Layer 1 · Install and build

Install, run, and build a project #

Each Junkpile example is an independent Tauri application. Install the platform prerequisites once, then run commands from the individual example folder you want to use.

1. Install the required tools

Tool	Purpose	Verify
Node.js and npm	Frontend dependencies and local project scripts	`node --version` `npm --version`
Rust and Cargo	Tauri backend and native wgpu projects	`rustc --version` `cargo --version`
Git	Clone and update the repository	`git --version`
System build tools	Compile native application dependencies	See the platform steps below

2. Install platform prerequisites

macOS

Install Apple command-line build tools

xcode-select --install

Metal is provided by macOS. Camera and microphone examples request permission when launched.

Windows

Install Microsoft Visual Studio Build Tools with the Desktop development with C++ workload. Install or update the WebView2 Runtime. A Direct3D 12-capable driver is recommended for native wgpu examples.

Linux

Install the Tauri WebKitGTK development packages required by your distribution. Native wgpu examples also require a working Vulkan or supported GL driver. MIDI examples commonly require ALSA development packages.

3. Download Junkpile

Clone the repository

git clone https://github.com/schwwaaa/junkpile.git
cd junkpile

You can also download the repository ZIP from GitHub and extract it locally.

4. Choose one example

Open the example catalog, copy the project folder name, and enter that folder. Do not run installation commands from the repository root unless a root script explicitly says to do so.

Tauri v1

cd v1/<example-folder>

Tauri v2

cd v2/<example-folder>

Native wgpu

cd native-wgpu/<example-folder>

5. Install and run the selected example

Development workflow

npm install
npm run dev

Use the local npm scripts. They invoke the Tauri CLI version configured for that project and avoid global Tauri v1/v2 command conflicts.

The first launch may take several minutes because Cargo downloads and compiles Rust dependencies. Later launches are substantially faster.

6. Build the standalone application

Production build

npm run build

Production bundles are normally created beneath:

Bundle output

src-tauri/target/release/bundle/

Platform	Typical output
macOS	`bundle/macos/.app` and, when configured, `bundle/dmg/.dmg`
Windows	`bundle/msi/.msi` or `bundle/nsis/.exe`
Linux	`bundle/appimage/*.AppImage`, Debian package, or another configured bundle target

7. Confirm the example is working

The application window opens without a Rust panic or blank WebView.
The expected shader, media source, or native GPU scene is visible.
Controls update the rendered output.
Reset, pause, fullscreen, and window-resize behavior work where documented.
Camera, microphone, MIDI, OSC, FFmpeg, Syphon, or Spout features are tested only when the example uses them.

Choose an example Installation troubleshooting Compare the tracks

Layer 1 · Choose deliberately

Which collection should you use? #

Need	Best starting track	Reason
p5.js, familiar browser APIs, rapid sketch-to-app work	Tauri v1 or v2 WebView	The renderer stays in HTML/JavaScript with GLSL ES.
Current Tauri permissions, native dialogs/drop, multi-window production examples	Tauri v2 WebView	Uses Tauri 2 capabilities and current WebView-window APIs.
Compute shaders, native GPU resources, 3D, Metal/Vulkan/DX12, 4K–8K export	Native wgpu	Rust owns the surface, device, queue, textures, buffers, and WGSL pipelines.
Compare architectural generations	Examples 00–09 across v1 and v2	The paired lessons reveal version changes without changing the core visual concept.
Build a focused media application	Examples 12–25, then native-wgpu equivalents	These examples cover playback, analysis, recording, compositing, automation, routing, and output.

Layer 2 · Technical comparison

Technology comparison at the implementation level #

The three Junkpile paths solve different layers of the same problem. They are not ranked from beginner to advanced. Each one defines who owns the renderer, where GPU resources live, how media crosses boundaries, and what kind of standalone application is easiest to build.

Technical concern	Tauri v1 WebView	Tauri v2 WebView	Native Rust/wgpu
Render ownership	Browser/WebView owns the drawing surface and render loop.	Browser/WebView owns the drawing surface and render loop, with newer Tauri window/capability APIs around it.	Rust owns the surface, device, queue, textures, buffers, passes, and present loop.
Primary graphics stack	HTML/CSS/JS + p5.js/WebGL.	HTML/CSS/JS + p5.js/WebGL or raw WebGL with current Tauri 2 APIs.	Rust + wgpu + WGSL, optional compute passes, explicit render graph structure.
Shader language	GLSL / GLSL ES inside WebGL.	GLSL / GLSL ES inside WebGL.	WGSL for render and compute pipelines.
UI layer	DOM UI inside the same application shell.	DOM UI with stronger native integration, dialogs, drag/drop, and capabilities.	Usually custom native UI or focused control panels; some projects keep the interface minimal and instrument-like.
Native boundary	Rust mostly supports the shell, window control, side services, or relays.	Rust exposes capabilities, file access, native dialogs, and service boundaries more cleanly.	Rust is the application core rather than a support layer.
Media and file I/O	Browser media elements are easy to use, but browser security and tainted-texture rules matter.	Same browser strengths, plus better current native file workflows and drop handling.	Native decoders, native camera/video bridges, explicit uploads, and direct file ownership are possible.
IPC / control topology	Simple one-window or two-window patterns, often with local relays for split control/render setups.	Same patterns, but updated APIs and clearer capability boundaries for multi-window applications.	Rust-side state and native event/control systems; no browser boundary is required unless intentionally added.
Best fit	Fast sketch-to-app work, approachable GPU experiments, and browser-native media logic.	Production-ready WebView tools that still benefit from web ergonomics.	High-performance GPU instruments, compute systems, 3D, heavy media routing, and larger export pipelines.
Main constraints	WebView behavior, browser path/security limits, and less direct GPU ownership.	Still a WebView renderer, so browser constraints remain even though shell behavior improves.	More code, more explicit resource management, and a higher implementation burden.

Practical rule: use WebView tracks when the browser is the right renderer, not because they are “less serious.” Use native wgpu when Rust must own GPU state, compute, media resources, or export at a deeper systems level.

Layer 2 · Software stack

The stack: from shared technology to standalone artist tools #

Junkpile demonstrates a software stack rather than one monolithic product. The idea is that artists and developers can build narrow, cross-platform standalone applications from reusable graphics and media patterns instead of starting from zero every time.

Cross-platform creative application stack

Artist need or instrument ideakeyer · feedback unit · recorder · mapper · router · player · automation tool

↓

Focused standalone applicationa single-purpose app with a clear UI and clear media behavior

↓

Junkpile architecture patternswindow topologies · controls · render loops · media loading · recording · error states

↓

Implementation trackTauri v1 WebView · Tauri v2 WebView · native Rust/wgpu

↓

Shared media and system servicescamera · files · audio · MIDI · OSC · FFmpeg · Syphon/Spout · GPU backends

↓

Cross-platform packaged applicationmacOS · Windows · Linux standalone delivery

Reusable foundation

Rendering, controls, media I/O, routing, fullscreen, timing, export, and recovery patterns are treated as reusable building blocks.

Focused tools

The commercial and artistic value comes from small, clear instruments—not from forcing every feature into one giant application.

Future direction

This stack points toward the broader Scheng model: common engine capability underneath deliberately independent standalone apps.

Layer 2 · Mental model

Three render ownership models #

WebView render path

InputDOM · camera · media · MIDI · OSC

↓

JavaScript stateparameters · transport · media elements

↓

p5.js / WebGL / GLSLrequestAnimationFrame inside WebView

↓

OS WebView renderer

Native wgpu render path

Input + HTML controlsnative capture · files · MIDI · OSC · Tauri IPC

↓

Rust canonical statecommands · queues · resource ownership

↓

wgpu / WGSLrender + compute pipelines

↓

Metal / Vulkan / Direct3D 12

Neither path is universally better. WebView examples are fast to understand and modify; native wgpu examples expose lower-level performance, compute, resource lifetime, and backend behavior.

Layer 2 · Windows and state

Window topologies #

Single window

Controls and renderer share one document or one hybrid window. State updates are direct and the lifecycle is compact.

Two WebViews + relay

Controls and canvas connect to the Rust WebSocket relay. Controls retain authoritative parameters; renderer-local media and GPU history stay in the canvas.

HTML controls + native renderer

A Tauri WebView owns the interface while Rust owns the wgpu surface. Commands cross IPC; large frame data should not.

State is not the same as GPU history. A reconnect can restore parameters, selected devices, and camera intent. It cannot recreate feedback textures or simulation buffers that belonged to a destroyed renderer; those resources must be initialized honestly.

Layer 2 · Technology families

What the examples now cover #

Shaders and graphics

p5.js, raw WebGL, external GLSL, live shader editing, WGSL, multipass graphs, compute, raymarching, meshes, skinning, and morphing.

Media and analysis

Images, webcam, native camera, video decoding, microphone/audio files, FFT, waveform textures, beat analysis, and image sequences.

Temporal systems

Framebuffer feedback, fluid simulation, history buffers, mesh feedback, recording, keyframes, transport, and synchronized outputs.

Control and interop

DOM controls, WebSockets, MIDI, OSC, pointer/touch/pen gestures, Max/MSP, TouchOSC, and native Tauri commands.

Compositing and live operation

Texture mixing, keying, Preview/Program switching, multi-input compositing, projection mapping, and multi-display management.

Resolution and export

High-DPI surfaces, 4K–8K working targets, PNG/JPEG output, recording, tiled GPU readback, and production bundles.

Layer 3 · Reliability lessons

What the modernization pass established #

Interface and control

Scrollable from the first layout pass with min-height: 0 on grid/flex children.
Fixed-width numeric readouts prevent layout movement.
High-rate sliders are coalesced to at most one send per animation frame.
Telemetry never overwrites a slider while the user is dragging it.
Pause, reset, fullscreen, presets, shortcuts, and runtime state are visible.

Renderer and media

Shader compile/link errors are visible; failed replacements retain the last valid program.
Camera and microphone lists refresh before and after permission.
Only newly decoded frames are uploaded.
Feedback targets are validated, explicitly cleared, and recreated on resize.
Native paths use Tauri drag/drop or Rust byte reads where browser security blocks texture upload.

Important fixes preserved in the documentation

p5 fullscreen vertex coordinates: convert 0–1 positions to clip space or output can appear in one quadrant. Global helper names: never declare function location() because it collides with window.location. Large binary output: avoid enormous JSON IPC payloads; use bounded chunks, commonly around 1 MiB. Image sequences: buffer before playback, default to hold-every-frame, and pause timing when decoding falls behind.

Collection A

Tauri v1 WebView · Examples 00–25 #

The v1 collection begins with paired p5.js, raw WebGL, external GLSL, camera, and feedback lessons; adds native MIDI and OSC bridges; then expands into production-oriented playback, analysis, recording, compositing, switching, mapping, automation, and display management.

Architecture: HTML/JavaScript renders in the WebView. Rust owns Tauri startup and selected native integrations. Use the v1 configuration schema and its feature model; do not copy Tauri 2 capability syntax into these projects.

Collection B

Tauri v2 WebView · Examples 00–25 #

The v2 collection preserves the understandable WebGL render path while using Tauri 2 configuration, explicit capabilities, window.__TAURI__.core.invoke(), current WebView-window APIs, native drag/drop, dialogs, and modern multi-window workflows.

Architecture: Tauri 2 does not automatically make a project a native GPU renderer. Examples in this collection still produce pixels through WebGL inside the WebView.

Collection C

Native Rust/wgpu · Examples 00–25 #

The native collection progresses from surface creation and WGSL to feedback, compute, high resolution, camera/video bridges, MIDI/OSC, gestures, multi-input compositing, glTF, skeletal animation, morph targets, persistent mesh deformation, and tiled 8K export.

Architecture: Rust owns the wgpu instance, surface, adapter, device, queue, textures, buffers, render/compute pipelines, and presentation. HTML controls remain optional and communicate through explicit state contracts.

Complete inventory

Example catalog #

Filter by collection or search by folder name, media source, technique, or lesson.

V1 00p5

p5.js Shader · Single Window

p5-tauri-single-template

p5.js WebGL shader baseline with controls and renderer in one WebView.

p5.js WebGLsingle-windowDOM controls

Status	Current evidence
Inventory and documentation	Example catalog cataloged; all three 00–25 collections complete.
Runtime	Primary workflows tested sequentially on macOS during development.
Standalone packaging	Every project documents local development and production build commands.
Windows/Linux	Architecture targets these platforms, but broad runtime verification remains future work; Spout implementation exists but was not fully tested in the primary cycle.
Hardware/network inputs	Camera, MIDI, OSC, Syphon, and external Max/MSP workflows were tested where hardware/platform access was available.

Three technical paths.One visible learning system.Many creative directions.

What Junkpile is #

Tauri v1 WebView

Tauri v2 WebView

Native wgpu

Run an example #

Install, run, and build a project #

1. Install the required tools

2. Install platform prerequisites

3. Download Junkpile

4. Choose one example

Tauri v1

Tauri v2

Native wgpu

5. Install and run the selected example

6. Build the standalone application

7. Confirm the example is working

Which collection should you use? #

Technology comparison at the implementation level #

The stack: from shared technology to standalone artist tools #

Reusable foundation

Focused tools

Future direction

Three render ownership models #

Window topologies #

Single window

Two WebViews + relay

HTML controls + native renderer

What the examples now cover #

Shaders and graphics

Media and analysis

Temporal systems

Control and interop

Compositing and live operation

Resolution and export

What the modernization pass established #

Interface and control

Renderer and media

Tauri v1 WebView · Examples 00–25 #

Tauri v2 WebView · Examples 00–25 #

Native Rust/wgpu · Examples 00–25 #

Example catalog #

p5.js Shader · Single Window

p5.js Shader · Two Window

Raw WebGL · Single Window

Raw WebGL · Two Window

External GLSL · Single Window

External GLSL · Two Window

Webcam Texture · Single Window

Webcam Texture · Two Window

Feedback Simulation · Single Window

Feedback Simulation · Two Window

MIDI Input

OSC Input

Video Texture Player

Audio-Reactive FFT

Canvas Recorder

Multipass Compositor

Image Texture Processor

GLSL Shader Playground

Texture Mixer

Webcam Compositor

Live Video Switcher

Projection Mapper

Image Sequence Player

Audio File FFT Visualizer

Keyframe Automation

Multi-Display Output Manager

p5.js Shader · Single Window

p5.js Shader · Two Window

Raw WebGL · Single Window

Raw WebGL · Two Window

External GLSL · Single Window

External GLSL · Two Window

Webcam Texture · Single Window

Webcam Texture · Two Window

Feedback Simulation · Single Window

Feedback Simulation · Two Window

MIDI Input

OSC Input

Three technical paths.
One visible learning system.
Many creative directions.