Trending:
Software Development

Developer pushes Pixi.js infinite canvas to 60,000 cards before performance breaks

Alan Senior's Pyramid Notes project confirms WebGL canvas libraries outperform DOM by 10x for visual collaboration tools. Real-world testing shows 60,000 unique cards render smoothly, 90,000+ crashes browsers. The findings matter for enterprise teams building Figma-style diagramming or note-taking platforms.

Developer pushes Pixi.js infinite canvas to 60,000 cards before performance breaks Photo by Polina ⠀ on Pexels

A developer building Pyramid Notes, an infinite canvas note-taking app, has documented the performance limits of Pixi.js for enterprise visual collaboration tools.

Alan Senior's testing shows DOM-based infinite canvases start lagging around 1,000 elements during zoom operations. Switching to Pixi.js (a WebGL canvas library) delivered 10x performance gains. His optimized implementation handles 60,000 unique cards smoothly, starts showing minor lag at 90,000, and crashes browsers past 95,000.

The DOM approach feels sluggish even in well-optimized tools like tldraw at 1,000 cards. Senior suspects text rendering and shadow effects compound the problem. Canvas-based approaches skip fewer frames during the critical zoom range where users notice performance issues.

Why this matters: The visual collaboration market (Miro, Figma analogs) exceeds $10 billion. Enterprise teams building diagramming, whiteboarding, or knowledge management tools need performance benchmarks for technology choices. Senior's work confirms WebGL approaches are necessary past 1,000 elements.

The implementation details: Senior used AABB (axis-aligned bounding box) culling, level-of-detail states, and tree-based layouts instead of flat structures. He generated 170,000 unique "words" (random character strings) to avoid unrealistic cache optimizations from Pixi.js's internal text caching.

His expected user base: 1,000-10,000 notes average, 20,000-50,000 for power users. The structured mode (tag visualization) can duplicate notes across the tree, potentially requiring higher render counts than the manual freeform mode.

The tradeoffs: Getting to 100,000 cards requires sacrificing level-of-detail quality. Senior recommends warning users to filter results past 60,000 rather than risk browser crashes. Generating test data remains slow (300 random ProseMirror documents maximum per batch).

Further optimization through object pooling is possible but adds code complexity Senior considers unjustified for realistic use cases. The 60,000-card threshold already exceeds expected enterprise deployment scenarios by 3-6x.