PixiJS Shared Ticker vs Application Ticker

In Pixi.js, managing the rendering loop and animations is handled by Tickers, which execute callback functions on every frame using requestAnimationFrame. This article explains the core differences between the shared global Ticker and an application-specific Ticker, detailing their behavior, lifecycle, and how to choose the right one for your project.

What is a Pixi.js Ticker?

A Ticker is a utility that runs a queue of listener functions once per frame. It is the heartbeat of any Pixi.js application, driving the rendering process and updating coordinate systems, animations, and game physics. Pixi.js provides two primary ways to utilize tickers: the shared global Ticker and the application-specific Ticker.

The Shared Global Ticker

The shared Ticker (PIXI.Ticker.shared) is a single, globally accessible instance of the Ticker class.

• Global Scope: It exists independently of any individual PIXI.Application instance. Any piece of code across your entire codebase can register a listener to it.
• Automatic Lifespan: By default, the shared Ticker starts automatically as soon as you add your first listener to it.
• Use Cases: It is ideal for global UI animations, background assets, or when you have multiple independent Pixi.js applications on a single page that need to stay synchronized to the exact same frame rate and time delta.

The Application-Specific Ticker

When you instantiate a new Pixi.js application using const app = new PIXI.Application(), it automatically creates its own internal ticker accessible via app.ticker.

• Instance Bound: This ticker is tied directly to the lifecycle of that specific PIXI.Application instance.
• Automatic Rendering: The application-specific ticker is hooked into the application’s rendering system by default. Every tick, it updates the stage and renders the scene to the canvas.
• Independent Control: You can stop, start, pause, or change the speed (speed property) of app.ticker without affecting any other tickers or applications running on the page.
• Use Cases: This is the standard choice for games, interactive animations, or component-based web designs where you need complete, isolated control over a single canvas’s frame loop.

Key Differences

1. Lifecycle and Memory Management

When you destroy a PIXI.Application using app.destroy(true, { children: true }), the application-specific app.ticker is automatically stopped and cleaned up. Conversely, the shared Ticker persists. If you register listeners to the shared Ticker, you must manually remove them when tearing down components to prevent memory leaks.

2. Playback Control

If you pause the shared Ticker via PIXI.Ticker.shared.stop(), every system, animation, and application relying on the shared ticker across your entire webpage will freeze. If you pause app.ticker.stop(), only that specific application will pause, leaving other canvas elements or global animations running smoothly.

3. Execution Order and Custom Rendering

Because app.ticker is pre-configured to handle the application’s render pass, adding listeners directly to it ensures your game logic updates right before the render happens. If you use the shared ticker, you have to be more deliberate about the order of execution if you want to avoid visual jitter or “lagging” frames.