Tricky JS and WebGL practices to achieve the best performance on mobile
summary
An interactive stadium seat map renders ~100k seats and pivots from server-side Electron/OpenGL on EC2 with GPU and Rust (fails after 15 minutes when virtual display sleeps) to client WebGL using pixijs then a hand-rolled renderer. Coordinate packing and run-length encoding shrinks gzip payloads ~17×. Pixi sprite creation costs ~400 ms (1.5 s on a high-end Android), 200 MB RAM and 100% CPU; the custom engine drops CPU to <1% and memory by half. Clicks use color-encoded offscreen IDs with readPixels and lazy per-seat object creation.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 1:12Speaker and context
- 2:17Large stadium seats challenges
- 3:04Server-side rendering first
- 4:10OpenGL on server side
- 6:01Mobile performance data rethink
- 7:08Run-length encoding coordinates
- 8:52PixiJS performance issues
- 10:47Custom WebGL solution
- 11:57Initial WebGL demo
- 13:30Memory and CPU profiling
- 14:33Custom WebGL results
- 16:04Click detection with pixels
- 17:31Off-screen click detection
- 19:42Large datasets handling
- 23:14Computing values on access
- 26:23Q&A
- 36:29Closing
related talks
43mWebGL 2D Rendering with PixiJS
58mMemes, Shaders and PixiJS: How an RTS on the Web Loads in 3 Seconds and Delivers 120 FPS
26mSVG, Canvas, and WebGL: The Power, the Beauty, and the Cost
20mOptimizing assets for graphics heavy Web Applicatoins: tips and tricks from the game dev background
58mRendering performance from the ground up
23mOptimizing HTML5 Games: 10 Years of Learnings
32mThe browser kicked me out (of the CPU): Making a three.js WebGL mobile game
28mTurbo charging 2D on the web