0Pricing
Flutter Mobile Development · Lesson

Shader Warm-Up and Impeller Migration

Eliminate first-run shader jank by precompiling shaders and adopting the Impeller renderer.

Shader Warm-Up and Impeller Migration is a free Flutter Mobile Development lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Flutter Mobile Development learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why First-Run Jank Happens

The first time a Flutter app draws a particular effect, the GPU backend has to compile the underlying shader program on the device. With the legacy Skia backend this compilation happens lazily, right in the middle of the frame that needs it.

  • A shader compile can take tens of milliseconds.
  • That blows the 16ms budget of a 60fps frame, producing a visible stutter called shader jank.
  • It is worst on the very first run because nothing is cached yet.

Animations, page transitions, and BackdropFilter blurs are the usual culprits.

Where the Time Goes

A jank frame caused by shader compilation shows up clearly in DevTools' Performance view as a tall raster-thread bar with a ShaderCompilation event.

To reproduce and measure it reliably, run in profile mode (never debug mode, which is much slower and misleading):

  • Profile mode gives release-like performance with tracing hooks.
  • The DevTools timeline marks shader compile events so you can confirm the root cause before optimizing.
// Run the app in profile mode to capture realistic frame timings.
// flutter run --profile

// Then open DevTools > Performance and look for
// 'ShaderCompilation' events on the raster thread.
// flutter run --profile --trace-skia

The Skia Warm-Up Strategy

On the legacy Skia backend, the classic fix is shader warm-up: collect the shaders your app uses into a bundle, then precompile them at startup before the user interacts.

Flutter generates this bundle for you with the --cache-sksl flag, which records SkSL (Skia Shader Language) programs while you exercise the app:

// 1. Run in profile mode, capturing SkSL while you navigate every screen
//    and trigger every animation that might cause jank.
// flutter run --profile --cache-sksl --purge-persistent-cache

// 2. In the running app, press 'M' in the terminal to write the
//    captured shaders to a JSON file, e.g. flutter_01.sksl.json

Bundling the Captured Shaders

Once you have the captured .sksl.json file, you bundle it into the release build. Flutter precompiles those shaders during the engine warm-up phase, so they are ready before the first frame the user sees.

  • Capture on a physical device similar to your target hardware.
  • Re-capture whenever the UI changes significantly.
// Bundle the captured SkSL into a release build:
// flutter build apk --bundle-sksl-path flutter_01.sksl.json
// flutter build ios --bundle-sksl-path flutter_01.sksl.json

// The engine warms up these shaders at launch,
// eliminating compile stalls during animations.

Why Skia Warm-Up Is a Band-Aid

SkSL warm-up works, but it has real downsides that motivated a deeper fix:

  • The capture is device- and driver-specific; a bundle from one GPU may not cover another.
  • You must remember to re-capture after UI changes, or jank silently returns.
  • It only covers the shaders you happened to exercise during capture.

The Flutter team's permanent answer is a new rendering engine that does not compile shaders at runtime at all: Impeller.

How Impeller Eliminates the Problem

Impeller precompiles a small, fixed set of shaders at engine build time rather than at runtime. Instead of generating arbitrary shaders per draw call, it composes effects from these known-ahead-of-time programs.

  • No runtime shader compilation means no first-run shader jank by design.
  • It uses Metal on iOS and Vulkan on modern Android.
  • Because shaders are known ahead of time, --cache-sksl warm-up is unnecessary and unsupported with Impeller.

Impeller's Default Status

Impeller is now the default renderer on iOS and on modern Android (devices supporting Vulkan), as of recent stable Flutter releases. On older Android hardware without Vulkan, the engine falls back to an OpenGL backend automatically.

Most apps get the benefit with no code change. The migration work is about verifying visual correctness and handling the few edge cases where Impeller and Skia differ.

Toggling Impeller Per Platform

You control Impeller through native platform manifests, not Dart code. This lets you opt in, opt out, or compare against Skia during migration testing.

On iOS, set the flag in Info.plist; on Android, in AndroidManifest.xml:

<!-- ios/Runner/Info.plist -->
<key>FLTEnableImpeller</key>
<true/>

<!-- android/app/src/main/AndroidManifest.xml (inside <application>) -->
<meta-data
    android:name="io.flutter.embedding.android.EnableImpeller"
    android:value="true" />

Custom Shaders Still Need Warm-Up

If you ship your own GLSL fragment shaders via FragmentProgram, those are your code and are not part of Impeller's built-in set. Compiling or loading them on demand can still stall a frame.

The fix is to load and warm them up during app startup, before they are first used in an animation:

import 'package:flutter/material.dart';

class ShaderCache {
  static FragmentProgram? ripple;

  // Call during startup so the program is ready before first paint.
  static Future<void> warmUp() async {
    ripple = await FragmentProgram.fromAsset('shaders/ripple.frag');
  }
}

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await ShaderCache.warmUp();
  runApp(const MyApp());
}

Pre-Rendering Expensive Effects

Even with shaders precompiled, the very first build of an expensive widget can still cost more than later builds. A common technique is to render the heavy effect off-screen during a splash or warm-up frame so the work is done before the user navigates to it.

You can drive a one-frame warm-up render after the first frame is committed:

import 'package:flutter/material.dart';
import 'package:flutter/scheduler.dart';

void scheduleWarmUp(VoidCallback warmUpExpensiveEffects) {
  // Runs once after the first frame is rendered,
  // so warm-up work does not block startup paint.
  SchedulerBinding.instance.addPostFrameCallback((_) {
    warmUpExpensiveEffects();
  });
}

Measuring the Win

Always confirm the improvement with data, not vibes. Compare the worst frame raster time before and after, on a real device, in profile mode.

You can compute simple statistics from captured frame timings to verify that the 99th-percentile frame now fits the budget:

void main() {
  // Raster times in milliseconds captured before the warm-up fix.
  final frames = <double>[8.1, 7.9, 42.6, 8.0, 9.3, 8.2, 7.7];

  frames.sort();
  final worst = frames.last;
  final p50 = frames[frames.length ~/ 2];
  const budget = 16.0; // 60fps frame budget

  print('p50: ${p50}ms  worst: ${worst}ms');
  print(worst > budget
      ? 'Jank present: worst frame exceeds ${budget}ms'
      : 'All frames within budget');
}

Quick Check

You migrate a C1-level app from Skia to Impeller to fix first-run shader jank. What happens to your existing SkSL warm-up bundle and why?

Recap

You now know how to eliminate first-run shader jank in Flutter:

  • Diagnose shader compilation stalls in DevTools' Performance view using profile mode.
  • Skia warm-up with --cache-sksl and --bundle-sksl-path precompiles captured SkSL, but is device-specific and brittle.
  • Impeller is the permanent fix: it precompiles a fixed shader set at build time, so there is no runtime compilation and no shader jank by design. It is the default on iOS and modern (Vulkan) Android.
  • Toggle Impeller via Info.plist and AndroidManifest.xml; drop your SkSL bundle once migrated.
  • Custom FragmentProgram shaders still need explicit startup warm-up.
  • Always measure worst-frame raster time on a real device to confirm the win.

Frequently asked questions

Is the “Shader Warm-Up and Impeller Migration” lesson free?

Yes — the full text of “Shader Warm-Up and Impeller Migration” is free to read here on the web, and the Flutter Mobile Development course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Flutter Mobile Development course, upgrade to CoddyKit PRO.

What will I learn in “Shader Warm-Up and Impeller Migration”?

Eliminate first-run shader jank by precompiling shaders and adopting the Impeller renderer. You practise Flutter Mobile Development with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Flutter Mobile Development?

No prior experience is required. Flutter Mobile Development on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Shader Warm-Up and Impeller Migration” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Flutter Mobile Development lesson?

Yes. Every Flutter Mobile Development lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. The Three Trees: Widget, Element, and RenderObject
  2. Profiling Jank with the DevTools Timeline
  3. RepaintBoundary, Const Widgets, and Rebuild Pruning
  4. Shader Warm-Up and Impeller Migration
← Back to Flutter Mobile Development