PixiJS中Geometry的用途是什么？与DisplayObject有何差异？

Great question—let’s break this down clearly since it’s easy to mix up these core Pixi.js concepts when digging into the source code.

What Exactly Is Geometry Used For? #

At its core, Geometry is a low-level container for raw graphical data that the GPU needs to render shapes, sprites, or meshes. Think of it as the blueprint for the pixels you see on screen: it stores things like:

• Vertex positions (x/y/z coordinates defining points in 2D/3D space)
• UV coordinates (mapping texture pixels to vertex positions)
• Color data per vertex
• Indexes (defining which vertices connect to form triangles, the GPU’s basic drawing primitive)

Pixi.js uses Geometry to abstract away WebGL buffer management: it handles creating, updating, and uploading these raw data arrays to the GPU efficiently. For example:

• When you create a Sprite, it uses a shared default quad (4-vertex) Geometry to render the texture onto a flat rectangle.
• When you draw shapes with Graphics, every line, curve, or polygon you define gets converted into a set of vertices stored in a Geometry instance, which the renderer then uses to fill or stroke the shape.

How Is Geometry Different from DisplayObject? #

The key difference boils down to responsibility and abstraction level:

• DisplayObject (and its subclasses like Container, Sprite, Graphics) are scene graph nodes. They handle:

  • Transformations (position, scale, rotation, pivot)
  • Visibility, alpha, and blend modes
  • Interaction (click events, hit testing)
  • Hierarchy (being added to a Container, managing children)
    In short, they’re the "logical" entities you add to your stage and manipulate to build your scene.

• Geometry is a pure data structure with no scene graph presence. It doesn’t have a position, can’t be added to a Container, and doesn’t handle any logic beyond storing and organizing the raw data needed for rendering. It’s the "building material" that renderable DisplayObjects (like Sprite or Mesh) use to define what gets drawn.

Where Does Geometry Fit Into the DisplayObject/Container/Sprite Render Tree? #

You’re right that DisplayObject, Container, and Sprite form a transform tree—each node applies its matrix transformations to itself and its children. Here’s how Geometry fits into this flow:

1. Containers don’t use Geometry at all—they’re just transform and hierarchy managers. They pass down their combined transform matrices to their renderable children.
2. Renderable DisplayObjects (like Sprite, Mesh, or Graphics) each hold a Geometry instance (or reference a shared one for efficiency). When the Renderer processes the scene tree:
   • It first calculates the final transform matrix for the DisplayObject (combining its own transform with all parent transforms).
   • It then takes the Geometry’s raw vertex data, applies that transform matrix to the vertices (or lets the GPU do it via shaders), and uses the resulting data to draw the shape/texture on screen.
3. For Graphics, every time you modify the shape (e.g., call drawCircle()), it regenerates its internal Geometry to reflect the new vertex data before the next render pass.

In other words: the transform tree handles where and how to render, while Geometry defines what to render.

内容的提问来源于stack exchange，提问作者Lance Pollard