The NEON rasterizer in neon_overlay.cpp is already the most taxing single pass in the pipeline. It runs only over the screen-space footprint of the dice — roughly 60,000–80,000 pixels per frame when several dice are in flight. Per batch of four pixels, the NEON path handles perspective-correct UV interpolation with two vector instructions, then falls back to scalar code for the texture fetch, tangent-space lighting, and framebuffer blend. Roughly ~20 floating-point operations per pixel, processed four at a time.
A separable Gaussian blur — the standard cheap blur — cannot skip empty pixels. It must iterate across the full framebuffer (750 × 560 = 420,000 pixels) in two passes (horizontal + vertical), reading
A bloom-quality radius (r ≈ 10) would put that ratio at ~50×. Even implementing the blur on a quarter-resolution downsampled copy (187 × 140 ≈ 26,000 pixels, which is the standard mobile game trick) would make it roughly cost-equivalent to the rasterizer — but then you have to add the downsample pass and the upsample composite, plus that second framebuffer allocation.
At 30 FPS on a 1.5 GHz dual-core Cortex-A7 with no GPU offloading, spending an entire "rasterizer's worth" of budget on blur for a subtle edge softening was not a trade I was willing to make.