The projection-matrix allows you to define a transformation from your “world” onto a part of the “canvas”. Yes, your scene graph lives in its own “world”, and you can move where it is rendered on the canvas independent of whether objects in your world are moving.

The positions you set for your display-objects are, by default, respective to the canvas coordinates. In other words, the “world” and the “canvas” are identical. However, a more flexible model where the two are independent.

Imagine an infinite plane, with a point set the “origin” and a grid to measure objects in pixels. Your scene graph lives on this 2D “world plane”, and you render a rectangle from this world (the source-frame) projected onto a rectangle in the canvas (the destination-frame). …

I’m excited to rollup out webdoc 1.0.0-RC this week. It’s aim is to be the all-encompassing solution for documenting libraries built with languages targeting the web.

Why?

No matter how useful your software is, no one will check it out without compelling documentation. It doesn’t make sense for documentation to be a last-priority item. It doesn’t help either that JSDoc, ESDoc, documentation.js, YUIDoc all are not actively maintained.

Clearly, innovation has fell off a cliff in this space — it’s this void that webdoc aims to fill.

What does webdoc have to offer over its competitors?

• It is much faster than JSDoc — building the PixiJS API documentation 67% faster! (from ~30s to just under…

Lerna is a great tool for keeping multiple packages in one repository.

However, it doesn’t provide a built-in solution for automating the build process. Here, I describe how you can create a build script that uses the RollupJS+Lerna API to:

• Compile packages in order of dependency
• Rebuild only packages that have changed
• Bundle multiple packages into one “super-bundle” to be consumed by the users — so they don’t have to build your whole project.

Setup

Instead of exporting a hardcoded, static configuration object, your rollup.config.js should generate one at runtime. The skeleton of the file would look like this:

async function main() {
  return {
    /* ... */
  };
}export default main();// @returns…

Learn about the official PixiJS GUI library with its diverse set of open-source widgets and layouts! — https://pixijs.io/pixi-ui

PixiJS is a fast, lightweight 2D rendering engine for the web. It is the go-to solution for creating rich, interactive, and fast content without the headache of diving into the WebGL API. For a long time, however, it has been lacking a comprehensive solution for GUI widgets that handle the rendering and interaction for you and expose an event-based API.

Nicholai Mortenson built a library called pixi-ui that got official support from PixiJS. Most of its use was through forking it into existing projects and converting it into an MVVM component. However, it was never published to npm and eventually fell out of maintenance. That’s why I took over the project and re-branded it as PuxiJS. I chose to name it Puxi because: i) this wasn’t going to be one plugin, but a monorepo of several components and I thought it deserved its own brand name, ii) the word contains “UX/UI” while being recognizably similar to Pixi. …

They’re collectively called the mid-level API!

PixiJS released a mid-level API in version 5. It exists between the WebGL layer and the high-level display-objects API. This API let’s you build custom display-objects and work directly with the WebGL renderer.

It consists of the three systems I’ve highlighted in the title:

• Geometry — This system manages attributes and vertex attribute objects (VAOs).
• Shader — This system manages uniforms and WebGL programs.
• State — This system allows you to atomically get and set all WebGL state variables — blend mode, culling, polygon offset, depth test, and winding.

This article is aimed at two key audiences: people interested in the internals of PixiJS & people interested in leveraging the new mid-level API. …

How does everything work?

A display-object is anything renderable in PixiJS. It must extend from PIXI.DisplayObject , or preferably PIXI.Container . These stub classes are a bit important to understand how the PixiJS UI is hierarchically organized and rendered.

DisplayObject

PIXI.DisplayObject is the base class of all renderable items. It provides the basic structure for them and integrates with PIXI.Container . I’ve listed important properties and methods below:

• alpha and worldAlpha : alpha specifies the opacity of this object w.r.t to the parent. worldAlpha is the “multiplied” alpha, or the opacity w.r.t. …

What’s hidden in this gem?

PixiJS has the concept of a “system-wide” renderer that fires every frame and makes the root display-object render itself. I cover these topics of the renderer here:

• Inheritance tree of renderers in PixiJS
• Systems architecture of the WebGL renderer
• Batching rendering

The WebGL renderer lives in the @pixi/core package as the Renderer class, which inherits from the AbstractRenderer class. Renderer was formerly named WebGLRenderer in PixiJS v4, but was renamed since the canvas-renderer was shipped only in the legacy bundle.

AbstractRenderer

What makes it so performant?

Batch rendering is what makes PixiJS the fastest WebGL drawing engine. It works by drawing groups of objects using their merged geometry. This technique reduces the number of draw calls and uploads to the GPU. There are a few limitations that come with batch rendering:

• Batched objects must have similar geometries, the same shaders, and the same number of textures.
• To maintain the order in which objects are being rendered, batched objects must be flushed prematurely if a dissimilar object is encountered.
• Geometries must be merged into one large buffer.

This article is aimed at two key audiences: people interested in the internals of PixiJS & people interested in extending batch rendering to their own display-objects. Here, I cover the object renderer, batch renderer, its plugin factory, and the batch system. …