Custom View from Scratch Part III: Performance and Optimisation
Article Summary
Eugene Zubkov from Revolut hit a wall building a custom Android chart: it literally disappeared due to texture size limits. His debugging journey reveals critical performance traps most Android devs don't see coming.
This is Part III of a deep-dive series on building custom Android views from scratch. Zubkov tackles the performance bottlenecks that emerge when Path rendering exceeds GPU texture limits (16384x16384 on most devices), causing views to vanish entirely.
Key Takeaways
- Path size directly determines texture size: larger paths create massive GPU textures
- Drawing primitives (drawLines) vastly outperforms Path rendering for complex charts
- TextureView enables threaded rendering without SurfaceView's animation restrictions
- Fixed-size charts with data shifting prevent unbounded Path growth
- Group primitives by type before drawing to maximize rendering speed
Moving from Path-based rendering to primitives and TextureView threading solved the texture overflow crash while dramatically improving frame rates.
About This Article
Eugene Zubkov's chart Path exceeded Android's maximum GPU texture size of 16384x16384, which caused the view to fail rendering with a shape-too-large error. The problem got worse as new data values kept accumulating.
Zubkov built a fixed-size chart that shifts data left and removes old values. He also used TextureView's dedicated rendering thread to move the Path-to-texture conversion work off the main thread.
The Profiler showed that frame rate stayed stable. Rendering performance no longer degraded when the chart received continuous new data updates.