Android · Flutter · AI Programming

Android Spine Gets a GPU Rendering Backend to Slash Memory with ASTC Textures

By JulyYu · Aug 19, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Mobile apps that embed Spine animations—avatar systems, game HUDs, sticker features—inherit a Canvas-based renderer that decodes every texture into a full RGBA8888 bitmap. Switching to an OpenGL ES backend with ASTC support removes that decode step and keeps textures compressed in GPU memory, which directly reduces OOM crashes on low-end devices and lets a single asset pipeline serve Cocos, native, and Flutter from one compressed file.

Summary

A team building a Cocos Creator-powered 3D avatar system hit memory limits when Spine PNG textures ballooned inside the engine. Cocos already supported ASTC compression, so the obvious next step was making the native Android and Flutter Spine runtimes consume the same compressed assets. The iOS port was straightforward; Android was not, because the official spine-android library deliberately avoids OpenGL and draws everything through Android's Canvas API.

Using Trae Work (ByteDance's AI coding tool), the developer reverse-engineered the rendering chain, confirmed that spine-libgdx provides a full OpenGL skeleton renderer, and generated a plan to swap the backend. The resulting AstcSpineView loads .astc files into GPU textures, fixes a fatal projection-matrix bug that caused a black screen, and eliminates per-frame allocations that triggered GC every 15 seconds. A second TextureView-based variant, AstcTextureSpineView, was added after GLSurfaceView proved incompatible with Flutter's Platform Views.

The final setup keeps the spine-libgdx logic layer intact while replacing Canvas with a dedicated GL render thread. ASTC textures stay compressed in VRAM, memory pressure drops sharply, and the animation view behaves like a standard Android View—supporting transparency, transformations, and lifecycle management.

Takeaways

— Official spine-android uses Canvas.drawVertices() and BitmapShader, not OpenGL, so it cannot consume GPU-compressed formats like ASTC.

— spine-libgdx already ships a complete OpenGL ES skeleton renderer; the Android port only reuses its logic layer and discards the GL rendering backend.

— Replacing Canvas with an OpenGL backend requires rewriting texture loading, projection matrices, blend-mode mapping, and the view container (GLSurfaceView or TextureView).

— A single sign error in the Y-axis translation and a projection matrix that fed pixel values into NDC clip space both produced a completely black screen.

— Per-frame object allocations in the render loop caused a GC trigger every 15 seconds; caching command arrays, reusing the MVP matrix, and hoisting dimension reads eliminated the churn.

— GLSurfaceView's independent Surface conflicts with Flutter's Skia/Impeller pipeline, causing coordinate misalignment; TextureView with self-managed EGL solved the overlay and transformation issues.

— ASTC textures reduced per-texture memory roughly 4–8× compared with the original RGBA8888 bitmaps, and file sizes shrank as well.

Conclusions

The spine-android library's choice of Canvas over OpenGL was a deliberate trade-off for easier View integration, but it locks out any GPU-native texture format—a constraint that becomes a hard wall once memory pressure matters.

AI coding tools accelerated the refactor not by writing flawless code on the first pass, but by rapidly generating the boilerplate OpenGL scaffolding (shader setup, EGL context management, texture loading) that developers typically find tedious and error-prone.

The GLSurfaceView-to-TextureView pivot highlights a recurring pain point in Flutter add-to-app scenarios: Platform Views that own a separate Surface often fight with Flutter's compositor, and TextureView is the more reliable bridge despite its own performance trade-offs.

Even with AI assistance, the developer still had to diagnose a black screen caused by a projection-matrix bug—proof that domain knowledge in graphics programming remains the backstop when generated code compiles but produces nothing.

Concepts & terms

ASTC (Adaptive Scalable Texture Compression)

A GPU-native texture compression format supported by modern mobile GPUs. Unlike PNG or JPEG, ASTC data stays compressed in video memory and is decoded on-the-fly by the GPU, cutting VRAM usage and eliminating the CPU-side decode step.

spine-libgdx

The official Spine runtime built on libGDX. It contains both the animation logic (skeleton updates, slot transforms) and a full OpenGL ES rendering backend, but the Android port discards the rendering layer in favor of Canvas.

Canvas.drawVertices()

An Android API that draws a mesh of vertices with optional texture coordinates. spine-android uses it to render skeleton meshes without touching OpenGL directly, though hardware acceleration may still route the work to the GPU.

GLSurfaceView vs. TextureView

GLSurfaceView creates a dedicated Surface behind the window, which gives direct GPU access but cannot be transformed or overlayed like a regular View. TextureView renders into a SurfaceTexture that the app can composite, making it compatible with View animations and Flutter Platform Views.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗