Culling, and how you can implement it in ten lines of code!

If your WebGL application has a very large scene that is only partially visible at any instant, then you can immediately improve performance by culling display-objects that are not visible.

You’re reading a chapter of “Inside PixiJS: WebGL Renderer”.


In computer graphics, there are multiple meanings of “culling”. The term here is used to describe the process of evaluating whether an object is “visible” and should be rendered at all. This allows the renderer to skip objects that do not need to be drawn, and reduces the number of draw calls per tick. …

And how you can optimize your scene graph!

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). …

What does it offer?

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.

Image for post
Image for post
webdoc’s simple logo!


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…

Learn how to use the RollupJS and Lerna API!

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.
Image for post
Image for post
Photo by Kevin Ku on Unsplash


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! —

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!

Image for post
Image for post

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?

Demo that uses PIXI.Ticker to manipulate a display-object’s rotation angle and scale w.r.t time!

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.


Image for post
Image for post

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?

Image for post
Image for post

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.


What makes it so performant?

Image for post
Image for post

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. …

Delivering efficient AI!

Let’s introduce you to the Minimax algorithm. I’ll explain some of its well known optimizations and some lesser known ones. This algorithm is useful in decision-making AI, which is used in popular game engines, like Stockfish for Chess. A major limitation of Minimax is that it is only used in two-player games.

Algorithm Basics

The Minimax algorithm can be thought of the computer playing against itself to find the best move! It follows the human thought process — if I do this move, what moves will my opponent have, then what moves can I play, and so on!

  • A naive implementation would keep on building the possible-moves tree until each “path” concludes into a win/loss. This isn’t practically possible because the size of the tree increases exponentially with each increment in search depth. …


Shukant Pal

Professional student freelancer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store