SKAkash GherWeb Developer & HTML5 Game Specialist
HomeCase StudiesProjectsBlogWritingStudioStoreLabsAbout
All Case Studies

Creative case study

Slot Game Performance Overhaul

10 March 2026
Sky
by sky
2 min readOptimizationPixiJSPerformance

Diagnosing and resolving critical performance bottlenecks in a live HTML5 slot title — achieving a 3x framerate improvement on mid-range Android devices.

PixiJS v7Chrome DevToolsSpectorJSTypeScriptWebGL
Case
Blogs
Writings
Studio
Labs
Home
Projects
Store
About

Client

Live iGaming Operator

Role

Performance Engineer

Year

2025

Discipline

Optimization

Slot Game Performance Overhaul
Doodle concept visual

Framerate on target Android device went from an average of 18 FPS to a stable 60 FPS without asset quality reduction.

The hero image is loaded from the MDX coverImage field. Replace the demo URL with your own gameplay capture, PixiJS canvas screenshot, or rendered artwork.

18 → 60

FPS improvement

94 → 8

Draw calls cut

40%

Memory reduction

On this page

  • The Situation
  • Diagnosis
  • Fixing the Rendering Pipeline
  • Texture Atlas Consolidation
  • Particle System Migration
  • Background & Idle Layers
  • Memory Leak Hunt
  • Result

Akash Gher

High-performance web experiences

Case StudiesProjectsStudioStoreLogin

© 2026 Akash Gher. All rights reserved.

The Situation

A live slot game with an existing player base was receiving complaints about poor performance on budget Android phones. The game ran well on desktop but suffered frame drops, jank, and occasional crashes on mobile. The operator could not afford a full rewrite.

Diagnosis

I started with SpectorJS to capture a WebGL frame and count draw calls. The result was alarming: 94 draw calls per frame for a relatively simple reel scene.

The culprits, identified by the capture:

  1. Every symbol was a standalone PIXI.Sprite loaded from individual PNG files — no texture atlas.
  2. Background layers, decorative elements, and particles all used different textures, breaking PixiJS's auto-batching on every switch.
  3. The background animation loop was running 30+ individual requestAnimationFrame callbacks simultaneously.

Fixing the Rendering Pipeline

Texture Atlas Consolidation

I ran all game assets through TexturePacker to generate two atlases: symbols.atlas and ui.atlas. This alone dropped draw calls from 94 to 22.

Particle System Migration

The win-burst effects were using PIXI.Container with individual sprite children. Migrating them to PIXI.ParticleContainer with pre-allocated capacity cut particle-related draw calls to 1 and eliminated GC pauses during big-win animations.

Background & Idle Layers

Background scroll layers were converted to PIXI.TilingSprite, eliminating the need for multiple sprites and reducing draw calls for the background to 2.

After all rendering fixes: 8 draw calls per frame.

Memory Leak Hunt

Chrome DevTools heap snapshots revealed that the bonus round screen was creating new PIXI.Text objects on every trigger without destroying the old ones. The fix was straightforward: a text object pool with a getText() / returnText() API.

A similar issue existed in the sound manager — Howler.js instances were being created without unloading, consuming growing amounts of audio buffer memory.

Result

Stable 60 FPS on the target device. Memory footprint reduced by 40%. Player complaints dropped to zero within two weeks of the patch going live. The profiling and fix methodology is now part of the team's internal QA checklist.

More Case Studies

You might also like

View all
iGaming Math Config Architecture
9 June 2026

iGaming Math Config Architecture

A technical deep-dive into how production iGaming studios store, version, and serve complex game math configurations across operators, jurisdictions, and variants.

Remote Gaming Server (RGS) Architecture
8 June 2026

Remote Gaming Server (RGS) Architecture

A complete blueprint of an enterprise iGaming backend system: from the Seven-Layer Model and 48ms game transaction loops to GLI compliance and scaling pipelines.

Lish Programming Language
6 June 2026

Lish Programming Language

An educational compiler project translating academic Computer Science theory into a working plain-English general-purpose compiler that compiles directly to zero-overhead x64 assembly.