Keeping the 2D Rendering Pipeline Visible
Raw2D is our low-level 2D rendering engine for JavaScript and TypeScript. It is browser-first, Canvas-first, and WebGL2-ready, but those labels are less important than the design decision underneath them: the path from scene data to pixels should remain understandable. We want developers building editors, visual tools, engine experiments, and browser experiences to be able to inspect that path, replace a piece of it, and explain what the renderer is doing without treating the engine as a sealed box.
A pipeline we can name
The public Raw2D pipeline is deliberately written in plain terms: Scene, RenderList, Batcher, Buffer, Shader, DrawCall. A Scene owns the objects that describe what should exist. A renderer decides how those objects become pixels. Between them, each stage has a focused responsibility that can be tested and diagnosed on its own.
That separation also shapes the object model. Objects store scene data and transform behavior; they do not contain Canvas or WebGL drawing code. Renderers own drawing. This prevents a rectangle, sprite, or text object from becoming coupled to one graphics backend, and it gives both renderer implementations a shared scene vocabulary.
Scene -> RenderList -> Batcher -> Buffer -> Shader -> DrawCallThe engine is most useful when a developer can follow an object all the way from scene data to a draw call.
Canvas as the reference, WebGL2 as an explicit path
Canvas is the complete reference renderer in Raw2D. It is the simplest place to start, the easiest path to debug, and a useful statement of expected behavior. A developer can create a Scene and Camera2D, add an object, and ask Canvas to render it without first learning a hidden runtime. That directness matters when the goal is to understand the engine as well as use it.
The WebGL2 renderer follows the same Renderer2DLike contract, but it exposes the performance-oriented machinery that makes its path different. It supports explicit batching, packed-atlas texture reuse, static render runs, opt-in safe sprite sorting, and renderer statistics such as draw calls and texture binds. We do not want WebGL2 to be a magic switch. Its benefits and constraints should be visible enough to measure.
Sharing a renderer contract lets application code choose the appropriate backend without moving drawing responsibilities back into scene objects. Canvas can remain the clarity-first implementation while WebGL2 develops the batching and buffer work needed by larger scenes.
Small packages around a stable center
Raw2D ships an umbrella package for the straightforward path and focused packages for engine builders. Core scene behavior, Canvas, WebGL, sprites, text, interaction, effects, React integration, and MCP automation live behind separate package boundaries. The packages are versioned together so a release remains easier to audit, even when an advanced project imports only the pieces it needs.
Interaction is intentionally outside the renderer. Selection, dragging, and resizing are tools that operate with the scene and camera rather than responsibilities buried inside a draw loop. The same principle applies to automation: raw2d-mcp works with scene JSON, validates unknown input, inspects renderer hints, and can generate Canvas or WebGL examples. The integrated Raw2D Studio uses the public APIs and keeps generated TypeScript beside the visual scene.
Constraints are part of the product
The repository enforces strict TypeScript, keeps React out of core packages, avoids an external rendering library, and asks modules to stay small and focused. Those rules are not decoration around the engine. They protect the quality that motivated Raw2D in the first place: readable internals and explicit ownership.
Raw2D is not trying to replace high-level engines such as PixiJS or Phaser. It serves a different need. When a project wants ready-made gameplay systems, a higher-level engine may be the right answer. When it needs direct control over the rendering pipeline, tooling-friendly APIs, and diagnostics that say what actually happened, a lower-level foundation earns its place.
Our measure of progress is therefore not how many details we can hide. It is whether the Canvas and WebGL2 paths can grow while the pipeline remains legible. Performance matters, but so does knowing where that performance came from.