Why PixiJS Is A Renderer And Not A Game Engine

Sat, 05 Sep 2026 13:22:38 +0000

A lot of the web game questions that land on here come down to picking a library before working out what kind of problem you actually have. This one catches people often enough that it is worth writing down for anyone about to start a browser game.

PixiJS does exactly one job: it draws 2D to a canvas, through WebGL, WebGPU, or Canvas 2D as a fallback, and it does that faster than almost anything else on the web. It manages a scene graph of display objects, sprites, text, graphics primitives and containers in a parent and child hierarchy, and renders that whole tree every frame.

What it does not ship is everything a framework bundles around a renderer. No physics engine, no scene manager in the game sense, no input abstraction, no audio system, no asset pipeline past texture loading, no editor. Those are not gaps. They are the reason it is fast.

The v8 trap

v8 was a rewrite rather than a version bump. The renderer was restructured, WebGPU became a first class backend alongside WebGL, and a fair amount of the older API surface moved. The practical effect is that much of the PixiJS material online is now quietly wrong. Guides written against v6 or v7 read correct and then fail in ways that look like your mistake rather than a version mismatch. Check the target version on anything you follow, before you follow it.

Where the performance actually goes

Optimization in Pixi almost always reduces to two things: how many draw calls you are issuing, and whether your textures live in atlases so they can batch. Objects sharing a texture batch into a single call. The library is fast by default and the ways to make it slow are specific and learnable.

The actual decision

Reach for PixiJS when rendering is the hard part and structure is not. A card game, a board game, a large 2D map, a data heavy interactive. Reach for a full framework like Phaser when you need physics, scenes, input and audio and would rather not assemble them yourself. Phaser used Pixi internally for years, so this is less a rivalry than a question of where you want the boundary between what you are handed and what you build.

The longer version is in this full guide to PixiJS game development, which covers the v8 architecture, the scene graph, animation and input, filters and shaders, the optimization work, and the comparison against full frameworks.

If you can describe your game as a rendering problem, use the renderer. If you cannot, use the framework.

How I Brought My Illustrations to Life with PixiJS: Parallax, Particles, and Sound in the Browser

Sat, 22 Aug 2026 10:55:09 +0000

How I Brought My Illustrations to Life with PixiJS: Parallax, Particles, and Sound in the Browser

I'm a book illustrator by trade. In 2012 I drew a piece called After Picasso — and at some point I realized a static image wasn't the end of the story for me. A side experiment with WebGL grew into a series I call Living Illustrations: finished illustrations, reopened — this time with depth, wind, and time inside them.

What is a "living illustration"?

Not a video, not a GIF. It's an interactive scene that responds to the visitor:

Mouse movement (or touch) drives the parallax
The scene has "sleep" and "awake" states
Audio only starts on a user gesture — which conveniently sidesteps browser autoplay policies

Anatomy of a scene: dissecting "After Picasso"

Layers. The illustration is cut into 6 PNG layers — background, midground, shadow, body, hand, foreground — each with its own zIndex and parallax coefficient, from 0.02 (background) to 0.12 (foreground). The closer the layer, the harder it reacts to the cursor. That coefficient gradient is what sells the depth.

Breathing. The body and hand layers slowly scale and shift on a sine curve, so the character appears to breathe. Cheap to compute, surprisingly effective.

The bird. Three flight frames, orbiting a point at (750, 420) with a ~500 px radius.

Particles. Up to 150 dust particles, color-locked to whichever zone of the artwork they rise from.

Twelve years later: "Pilot" (2024)

Same idea, different league:

The campfire is a sprite sheet (8×4 frames) driven by a full state machine: sleep → invite → awake → active → peak → fade, with spark bursts in the active phase
8 parallax layers, including two moons at different depths
A soundscape: campfire, dusk in the woods, wind

The stack

PixiJS (WebGL) for rendering — with a static-image fallback when WebGL isn't available
Vite for the build (hashed assets)
Howler / Tone.js for audio
A custom shader with subtle noise (uNoiseIntensity: 0.01) and chromatic aberration, so the scene feels alive even when nothing is moving

What this taught me as an artist

Draw in layers from day one. If you might animate an illustration later, separate it into planes while drawing, not after.
Performance is part of the composition. 150 particles isn't arbitrary — it's a budget.
Side projects with no deadlines are the best way to learn a new tool. This whole series started as an experiment that refused to stay small.

Fun fact: the section is deliberately hidden from search engines (noindex) and removed from my site's navigation — a private lab I've decided to open up a little.

Try the scenes yourself: vimark.art/living-illustrations

Coder Legion - Recent posts tagged pixijs

Why PixiJS Is A Renderer And Not A Game Engine

The v8 trap

Where the performance actually goes

The actual decision

How I Brought My Illustrations to Life with PixiJS: Parallax, Particles, and Sound in the Browser

How I Brought My Illustrations to Life with PixiJS: Parallax, Particles, and Sound in the Browser

What is a "living illustration"?

Anatomy of a scene: dissecting "After Picasso"

Twelve years later: "Pilot" (2024)

The stack

What this taught me as an artist