agentleFS
talesofaitalesofai/cohub/.agents/skills/pixijs-core-concepts/SKILL.md

pixijs-core-concepts

Skill571 starsChanged 3 months agoApache-2.0View on GitHub

Use this skill when understanding how PixiJS v8 renders frames: the systems-and-pipes renderer, the render loop, and how the library adapts to different environments. Covers WebGLRenderer/WebGPURenderer/CanvasRenderer selection, renderer.render() pipeline, environment detection, and pointers to per-topic deep dives. Triggers on: renderer, WebGL, WebGPU, Canvas, render loop, render pipeline, systems, environments, autoDetectRenderer.

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Setting up an Application?: Start with pixijs-application.

    line 39
  2. Very specific:

    Choosing between WebGL and WebGPU?: Use ['webgpu', 'webgl'] as your preference array.

    line 40
  3. Very specific:

    Integrating with a physics library?: Add your update at UPDATE_PRIORITY.HIGH so physics runs before the render at LOW.

    line 43
  4. Very specific:

    Running under strict CSP?: Import 'pixi.js/unsafe-eval'.

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Foundational model for how PixiJS v8 gets pixels on the screen: the renderer decides which GPU backend to use, the render loop drives per-frame work, and the environment layer adapts the library to browser, Web Worker, or SSR contexts. For the scene graph itself (Containers, transforms, destroy), see pixijs-scene-core-concepts.

Quick Start

console.log(app.renderer.name); // 'webgl' | 'webgpu' | 'canvas'

app.ticker.add((ticker) => {
  sprite.rotation += 0.01 * ticker.deltaTime;
});

const tex = app.renderer.extract.texture({ target: app.stage });

app.renderer.render({ container: app.stage });

app.renderer is the WebGLRenderer, WebGPURenderer, or CanvasRenderer chosen by autoDetectRenderer. The TickerPlugin drives renderer.render() automatically; call it manually only with autoStart: false. Backend selection happens in Application.init({ preference }); see pixijs-application for setup.

Related skills: pixijs-application (Application construction and lifecycle), pixijs-ticker (per-frame logic, priorities, FPS capping), pixijs-environments (Web Worker, SSR, strict CSP), pixijs-custom-rendering (writing a RenderPipe), pixijs-scene-core-concepts (scene graph basics).

Topics

TopicReferenceWhen
Choosing a backendreferences/renderers.mdPreference forms, per-renderer options, systems and pipes
Per-frame executionreferences/render-loop.mdPriority order, time units, manual rendering

For deep dives into any single topic, open the corresponding reference file. Non-browser targets (DOMAdapter, WebWorkerAdapter, custom adapters, strict CSP) are covered in the pixijs-environments skill.

Decision guide

  • Setting up an Application? Start with pixijs-application. This skill explains what the renderer does under the hood.
  • Choosing between WebGL and WebGPU? Use ['webgpu', 'webgl'] as your preference array. WebGPU is fastest where available; WebGL is the reliable fallback. See references/renderers.md.
  • Running in a Web Worker? Set DOMAdapter.set(WebWorkerAdapter) before app.init. See the pixijs-environments skill for complete setup.
  • Need manual control over when rendering happens? Set autoStart: false and call app.renderer.render(app.stage) from your own loop. See references/render-loop.md.
  • Integrating with a physics library? Add your update at UPDATE_PRIORITY.HIGH so physics runs before the render at LOW. See references/render-loop.md.
  • Writing a custom renderable? Implement a RenderPipe. See pixijs-custom-rendering skill.
  • Running under strict CSP? Import 'pixi.js/unsafe-eval'. See the pixijs-environments skill.

Quick concepts

Renderer = systems + pipes

Each renderer is composed of Systems (lifecycle services: textures, buffers, state, filters, masks) and RenderPipes (per-renderable instruction builders: sprite, graphics, mesh, particle, text, tiling). Writing a custom renderable means implementing a RenderPipe and registering it via extensions.

The render loop

app.ticker.add(fn) registers a callback that runs every frame. The TickerPlugin registers app.render() at UPDATE_PRIORITY.LOW, so ticker callbacks at NORMAL or HIGH run before the draw. Disable the plugin with autoStart: false for manual control.

Environments

DOMAdapter abstracts every DOM call PixiJS makes (canvas creation, image loading, fetch, XML parsing). Swap with DOMAdapter.set(WebWorkerAdapter) for Workers or implement a custom Adapter for Node/SSR. Must be done before Application.init.

Common Mistakes

[HIGH] Accessing app.renderer before init() resolves

Wrong:

const app = new Application();
app.init({ width: 800, height: 600 });
console.log(app.renderer.name); // undefined — init() is async

Correct:

const app = new Application();
await app.init({ width: 800, height: 600 });
console.log(app.renderer.name); // 'webgl' | 'webgpu' | 'canvas'

Application.init() is async. app.renderer, app.canvas, and app.screen do not exist until after the promise resolves.

[HIGH] Setting DOMAdapter after Application.init

Wrong:

const app = new Application();
await app.init({ width: 800, height: 600 });
DOMAdapter.set(WebWorkerAdapter); // too late — init already allocated resources

Correct:

DOMAdapter.set(WebWorkerAdapter);
const app = new Application();
await app.init({ width: 800, height: 600 });

The adapter abstracts DOM calls the renderer makes during construction (canvas creation, image loading, fetch). Swap it before init() or the wrong adapter is baked into the renderer.

[MEDIUM] Treating preference as a guarantee

Wrong:

await app.init({ preference: "webgpu" });
// assume WebGPU is active
useWebGPUOnlyFeature(app.renderer);

Correct:

await app.init({ preference: "webgpu" });
if (app.renderer.name === "webgpu") {
  useWebGPUOnlyFeature(app.renderer);
}

preference is a hint, not a demand. If the browser lacks WebGPU support, PixiJS falls back to WebGL (or Canvas). Always branch on renderer.name for backend-specific code.

API Reference

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.