Skip to main content

Impeller vs Skia: Troubleshooting Android Rendering Stutter in Flutter 3.x

 The transition to Impeller as the default renderer in Flutter 3.16+ promised the end of shader compilation jank. For iOS, this promise was largely kept. However, on Android, the ecosystem's hardware fragmentation has introduced a new class of rendering artifacts: frame pacing stutters, surface synchronization failures, and visual glitching on specific subsets of devices (notably Samsung Exynos variants and older Adreno drivers).

If your performance metrics show low UI thread usage (build times < 8ms) but high Raster thread usage or erratic frame presentation times, you are likely hitting edge cases in the Impeller Vulkan backend.

The Root Cause: Vulkan Driver Fragmentation

Under the hood, Impeller on Android targets the Vulkan API by default, whereas Skia primarily utilized OpenGL ES.

Vulkan is an explicit API; it shifts the responsibility of memory management and synchronization from the driver to the engine (Impeller). While this allows for greater performance control, it assumes the underlying GPU driver implements the Vulkan specification correctly.

The stuttering observed on devices like the Galaxy S22/S23 is often not "jank" in the traditional sense (dropped frames due to heavy computation). Instead, it is often:

  1. Swapchain Synchronization Issues: The engine submits a frame to the GPU, but the synchronization primitives (semaphores/fences) used to coordinate with the Android SurfaceFlinger encounter driver bugs. This causes the display to repeat the previous frame while waiting, resulting in perceived stutter despite high FPS logs.
  2. Texture Memory Thrashing: On devices with aggressive memory management or buggy VRAM allocation in their Vulkan drivers, Impeller may be forced to perform expensive texture uploads mid-frame.
  3. MSAA Resolution: Incompatibilities in how the GPU handles multisample anti-aliasing resolve attachments in Vulkan can lead to visual artifacts or massive GPU overhead.

The Solution

There are two phases to fixing this: Instrumentation (to confirm the issue isn't your code) and Mitigation (configuration changes).

Phase 1: Programmatic Jank Detection

Before applying engine flags, implement a FrameTiming observer to differentiate between UI Build Jank (your Dart code) and Raster Jank (the Engine/GPU). If Raster duration is high while Build duration is low, the issue lies with the renderer.

Add this monitoring logic to your entry point:

// lib/main.dart
import 'dart:ui';
import 'package:flutter/material.dart';
import 'package:flutter/scheduler.dart';

void main() {
  runApp(const MyApp());
  
  // Register a timing callback to detect raster jank
  SchedulerBinding.instance.addTimingsCallback((List<FrameTiming> timings) {
    for (final timing in timings) {
      final durationBuild = timing.buildDuration.inMilliseconds;
      final durationRaster = timing.rasterDuration.inMilliseconds;
      
      // Standard 60Hz frame budget is ~16ms. 
      // We set a threshold of 18ms to allow for minor fluctuations.
      if (durationRaster > 18 && durationBuild < 10) {
        print('[JANK DETECTED] Raster: ${durationRaster}ms | Build: ${durationBuild}ms');
        
        // TODO: Send this event to Sentry/Firebase/Datadog
        // Metadata: Device Model, OS Version, Renderer (Impeller/Skia)
      }
    }
  });
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Impeller Diagnostics',
      theme: ThemeData(
        useMaterial3: true,
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.blue),
      ),
      home: const Scaffold(body: Center(child: Text("Performance Test"))),
    );
  }
}

Phase 2: The Production Fix (The Fallback)

If your analytics confirm that users are experiencing raster jank on Android despite optimized Dart code, the immediate production fix is to disable the Vulkan backend or revert to Skia for Android.

While the Flutter team is actively patching Impeller, you cannot ship a broken UI to production. You have two options via AndroidManifest.xml.

Option A: Force OpenGL Backend (Keep Impeller, drop Vulkan)

Impeller has an OpenGL ES backend. This is often more stable on older devices than Vulkan, though slightly less performant than a tuned Vulkan pipeline.

<!-- android/app/src/main/AndroidManifest.xml -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application
        android:label="My App"
        android:name="${applicationName}"
        android:icon="@mipmap/ic_launcher">
        
        <!-- FORCE OPENGL FOR IMPELLER -->
        <!-- This keeps Impeller enabled but swaps the underlying API to GLES -->
        <meta-data
            android:name="io.flutter.embedding.android.ImpellerBackend"
            android:value="opengles" />

        <activity 
            android:name=".MainActivity"
            ...>
            <!-- Activity Config -->
        </activity>
    </application>
</manifest>

Option B: The "Nuclear" Option (Disable Impeller Completely)

If visual artifacts (flickering, texture corruption) persist even with the OpenGL backend, you must revert to the legacy Skia renderer. This is the most stable configuration for Flutter 3.19/3.22 on problematic Samsung devices.

<!-- android/app/src/main/AndroidManifest.xml -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application>
        <!-- ... other config ... -->

        <!-- DISABLE IMPELLER (REVERT TO SKIA) -->
        <meta-data
            android:name="io.flutter.embedding.android.EnableImpeller"
            android:value="false" />
            
    </application>
</manifest>

Why This Works

Breaking the Dependency on Buggy Drivers

By setting EnableImpeller to false, you force the Flutter engine to instantiate the legacy GrContext (Skia's GPU context). Skia has had nearly a decade of battle-testing against Android's fragmented driver ecosystem. It contains hundreds of vendor-specific workarounds (quirks modes) that Impeller—being a rewrite from scratch—has not yet fully accumulated.

The Trade-off

Disabling Impeller on Android brings back shader compilation jank. When a new animation plays for the first time, Skia must compile the GLSL shaders, causing a momentary freeze.

To mitigate this when reverting to Skia, you should ideally warm up your shader cache. However, for many business applications, a few missed frames during initial navigation (Skia) are preferable to constant micro-stuttering and visual corruption (Impeller on bad drivers).

Conclusion

Impeller is the future of Flutter, but the reality of Android hardware requires pragmatism. If your telemetry indicates high rasterization times on specific OEMs, do not hesitate to use the manifest flags to revert to OpenGL or Skia. Stability trumps theoretical performance improvements. Monitor the Flutter Engine changelogs for specific Vulkan driver patches before re-enabling Impeller in future releases.

Labels: