When you write Flutter code, you usually think in terms of widgets:

Container(
  padding: const EdgeInsets.all(16),
  child: const Text('Hello Flutter'),
)

However, Flutter does much more behind the scenes before that Text appears as pixels on the screen.

A simplified rendering pipeline looks like this:

Widget Configuration
        ↓
Build
        ↓
Layout
        ↓
Paint
        ↓
Compositing
        ↓
Rasterization
        ↓
Pixels on Screen

Understanding these stages is extremely useful when optimizing Flutter applications.

For example, if an application is janky, the problem might not be excessive widget rebuilding. The actual bottleneck could be expensive layout calculations, painting, image decoding, shadows, clipping, or rasterization.

In this guide, we’ll understand Build, Layout, Paint, and Raster in Flutter, how they differ, what triggers them, and how to identify performance problems in each stage.

---

Why Should Flutter Developers Understand the Rendering Pipeline?

Consider an animated screen that occasionally drops frames.

You might immediately think:

“Too many widgets are rebuilding.”

That is possible, but it is only one potential cause.

The problem could instead be:

Too much Build work
        ↓
Expensive Layout
        ↓
Expensive Painting
        ↓
Heavy Rasterization

Each problem requires a different solution.

For example:

Build problem
→ Reduce unnecessary rebuilds

Layout problem
→ Simplify expensive layouts

Paint problem
→ Reduce unnecessary repainting

Raster problem
→ Reduce expensive graphical operations

Therefore, understanding the rendering pipeline helps you optimize the actual bottleneck rather than guessing.

---

The Flutter Rendering Pipeline

At a high level, Flutter turns your Dart UI code into pixels through several stages.

Suppose you create:

Scaffold(
  body: Center(
    child: Container(
      width: 200,
      height: 100,
      color: Colors.blue,
      child: const Text('Hello'),
    ),
  ),
)

Flutter cannot simply send these widgets directly to the GPU.

Instead, several transformations happen.

Conceptually:

Widget Tree
     ↓
Element Tree
     ↓
RenderObject Tree
     ↓
Layout
     ↓
Paint Commands
     ↓
Layer/Scene Composition
     ↓
Rasterization
     ↓
GPU
     ↓
Screen

Let’s understand the important parts individually.

---

1. Build Phase in Flutter

The Build phase determines what the UI should look like based on the current application state.

Every Flutter developer has written a build() method:

@override
Widget build(BuildContext context) {
  return const Text(
    'Hello Flutter',
  );
}

The build() method returns a widget configuration.

Widgets themselves are lightweight, immutable descriptions of UI.

For example:

const Text('Hello')

describes a piece of UI.

It is not directly responsible for drawing pixels.

---

What Happens During Build?

During the Build phase, Flutter evaluates widget configurations and updates the corresponding element tree.

Consider:

Column(
  children: [
    const Text('Profile'),
    Text(username),
    ElevatedButton(
      onPressed: updateProfile,
      child: const Text('Update'),
    ),
  ],
)

Flutter creates or updates the relevant elements corresponding to these widgets.

A simplified relationship is:

Widget
   ↓
Element
   ↓
RenderObject

Widgets describe configuration.

Elements manage widget instances and their position in the tree.

Render objects handle operations such as layout and painting.

---

What Triggers a Rebuild?

A rebuild can happen when Flutter determines that a widget needs to be rebuilt.

A common example is setState():

setState(() {
  counter++;
});

The associated State object becomes dirty, and Flutter schedules the relevant build work.

Other state-management approaches can also trigger rebuilding of subscribed UI.

For example:

ChangeNotifier
ValueNotifier
Bloc
Riverpod
GetX
InheritedWidget
Streams

The exact behavior depends on how the state is scoped and consumed.

---

Example of Unnecessary Rebuilds

Consider:

class HomeScreen extends StatefulWidget {
  const HomeScreen({super.key});

  @override
  State<HomeScreen> createState() => _HomeScreenState();
}

class _HomeScreenState extends State<HomeScreen> {
  int counter = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        const ComplexHeader(),
        const LargeProductSection(),
        Text('$counter'),
        ElevatedButton(
          onPressed: () {
            setState(() {
              counter++;
            });
          },
          child: const Text('Increase'),
        ),
      ],
    );
  }
}

Every time counter changes, _HomeScreenState.build() runs again.

That does not necessarily mean every descendant performs expensive work or every pixel gets repainted, but rebuilding a larger subtree than necessary can still add overhead.

A better structure may isolate frequently changing state.

For example:

ValueListenableBuilder<int>(
  valueListenable: counterNotifier,
  builder: (context, counter, child) {
    return Text('$counter');
  },
)

Now the changing state can be consumed closer to the widget that actually needs it.

---

How to Reduce Build Cost

Common techniques include:

Use const Widgets

Instead of:

Text('Welcome')

prefer:

const Text('Welcome')

when possible.

Keep State Local

Avoid rebuilding an entire screen for a small state change.

Instead of managing everything at the highest level:

Page State
    ↓
Entire page rebuild

prefer more focused state:

Page
 ├── Static Header
 ├── Static Content
 └── Counter State
       ↓
     Counter

Extract Complex Widgets

For example:

Column(
  children: [
    const ProfileHeader(),
    const StatisticsSection(),
    CounterSection(),
  ],
)

Breaking the UI into meaningful components can make state and rebuild boundaries easier to reason about.

---

2. Layout Phase in Flutter

Once Flutter knows which render objects should exist, it needs to determine their sizes and positions.

That happens during the Layout phase.

Flutter’s layout system follows one important rule:

Constraints go down. Sizes go up. Parents set positions.

This principle explains a large part of Flutter layout behavior.

---

Understanding Constraints Go Down

Imagine:

Center(
  child: Container(
    width: 200,
    height: 100,
  ),
)

The parent provides constraints to its child.

Conceptually:

Screen
  ↓
Center receives constraints
  ↓
Center sends constraints to Container

A constraint might effectively describe limits such as:

Minimum width
Maximum width
Minimum height
Maximum height

The child chooses a size that satisfies those constraints.

---

Sizes Go Up

After receiving constraints, the child determines its size.

Conceptually:

Parent
   ↓
Constraints

Child
   ↓
Chooses Size

Parent
   ↑
Child Size

The parent can then use that information when positioning the child.

---

Parents Set Positions

The parent decides where its children should be placed.

For example, Row positions children horizontally.

Row(
  children: const [
    Icon(Icons.home),
    Text('Home'),
  ],
)

Conceptually:

Row
 ├── Icon  → position X
 └── Text  → position X + icon width

---

What Can Trigger Layout?

Layout is required when something affecting geometry changes.

Examples include:

Width
Height
Padding
Margin-related structure
Constraints
Text dimensions
Parent size
Child size
Flex configuration
Orientation

For example:

AnimatedContainer(
  duration: const Duration(milliseconds: 300),
  width: expanded ? 300 : 100,
  height: 100,
)

Because the width changes during the animation, layout work may occur repeatedly.

---

Layout Can Be Expensive

Simple layout operations are generally fast.

However, complicated trees can increase layout cost.

For example:

Deep nested layouts
Complex intrinsic measurements
Large render trees
Frequently changing sizes
Repeated layout during animations

Widgets involving intrinsic measurements deserve particular attention because determining their size may require additional measurement work.

Examples include:

IntrinsicHeight(...)

and:

IntrinsicWidth(...)

They are useful in some situations, but should not be used casually in performance-sensitive areas.

---

Build vs Layout

A rebuild and a relayout are different operations.

Consider:

Container(
  color: isActive
      ? Colors.green
      : Colors.red,
)

Changing only the color can change visual output without necessarily changing geometry.

Compare that with:

Container(
  width: isExpanded ? 300 : 100,
)

Now geometry changes, so layout may need to be recalculated.

Think of the difference as:

Build
→ What widgets/configuration should exist?

Layout
→ How large are the render objects and where should they go?

---

3. Paint Phase in Flutter

After Flutter determines sizes and positions, it needs to describe how those render objects should look.

This happens during the Paint phase.

Painting generates drawing commands.

Examples include:

Draw rectangle
Draw text
Draw image
Draw border
Draw path
Draw shadow
Draw gradient
Clip content

For example:

Container(
  width: 200,
  height: 100,
  decoration: BoxDecoration(
    color: Colors.blue,
    borderRadius: BorderRadius.circular(16),
  ),
)

Flutter eventually generates the necessary painting operations to represent that visual content.

---

CustomPainter and the Paint Phase

CustomPainter provides a very direct example of painting.

class CirclePainter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {
    final paint = Paint();

    canvas.drawCircle(
      Offset(
        size.width / 2,
        size.height / 2,
      ),
      50,
      paint,
    );
  }

  @override
  bool shouldRepaint(
    covariant CirclePainter oldDelegate,
  ) {
    return false;
  }
}

The paint() method receives:

Canvas canvas
Size size

and generates drawing operations.

You can draw:

Lines
Circles
Rectangles
Paths
Images
Text
Custom shapes

This makes CustomPainter powerful, but complex painting can also become expensive.

---

What Causes Repainting?

A render object may need repainting when its visual appearance changes.

Examples include:

Color changes
Decoration changes
CustomPainter changes
Animation changes
Image changes
Visual effects change

Imagine:

AnimatedContainer(
  duration: const Duration(milliseconds: 500),
  color: active ? Colors.green : Colors.red,
)

As the color changes during the animation, new frames need to be painted.

---

Repainting Can Spread

Consider:

Dashboard
 ├── Header
 ├── Statistics
 ├── Animated Chart
 └── Recent Orders

The chart updates continuously.

Depending on the render tree and existing repaint boundaries, painting work can involve a larger region than the widget that visually changed.

This is where RepaintBoundary becomes useful.

---

RepaintBoundary

You can isolate painting work with:

RepaintBoundary(
  child: AnimatedChart(),
)

Conceptually:

Dashboard
 ├── Header
 ├── Statistics
 ├── RepaintBoundary
 │      └── Animated Chart
 └── Recent Orders

Now the animated section has its own repaint boundary.

This can help Flutter reuse unchanged surrounding content rather than unnecessarily repainting it.

However, RepaintBoundary should be used strategically because extra boundaries can introduce additional layers and memory/compositing overhead.

---

Build vs Paint

This difference is extremely important.

A widget can rebuild without necessarily causing an expensive repaint.

Likewise, painting can occur because visual output changes.

Think of it like this:

Build
→ Update UI configuration

Paint
→ Generate visual drawing commands

Therefore:

Rebuild ≠ Repaint

Trying to solve repaint problems only by reducing build() calls can miss the actual bottleneck.

---

4. Compositing Phase

Between painting and rasterization, Flutter may organize painted content into layers.

This is known as compositing.

A simplified pipeline is:

Build
   ↓
Layout
   ↓
Paint
   ↓
Layers
   ↓
Compositing
   ↓
Raster

Layers allow Flutter to manage independently changing visual content efficiently.

For example, operations involving:

Transforms
Clipping
Opacity
Platform views
Repaint boundaries
Certain visual effects

may influence the layer structure.

---

Why Layers Matter

Imagine a static background with an animated object:

Background
     +
Animated Object

If they can be represented separately, Flutter may be able to reuse the unchanged background while updating the dynamic content.

Conceptually:

Layer 1
→ Static Background

Layer 2
→ Animated Object

Then those layers are composed together.

However, layers also have a cost.

Creating too many unnecessary layers can increase memory usage and compositing complexity.

This is one reason you should not blindly wrap everything with RepaintBoundary.

---

5. Raster Phase in Flutter

Painting commands are still not the final pixels displayed on the screen.

They describe what needs to be drawn.

The Raster phase converts those drawing operations into pixels.

A simplified flow is:

Paint Commands
      ↓
Layer/Scene Data
      ↓
Rasterizer
      ↓
GPU work
      ↓
Pixels
      ↓
Display

Flutter’s rendering engine handles this process using its graphics stack.

On modern Flutter platforms, Impeller is increasingly the primary rendering engine, although exact rendering behavior depends on the target platform and Flutter version.

---

What Makes Rasterization Expensive?

Some graphical operations are significantly more expensive than simple shapes or text.

Common examples can include:

Large Images

Displaying or transforming large images can increase rendering workload and memory usage.

Blur Effects

For example:

BackdropFilter(
  filter: ImageFilter.blur(
    sigmaX: 20,
    sigmaY: 20,
  ),
  child: Container(),
)

Blur can be expensive because many pixels must be processed.

Complex Shadows

For example:

BoxShadow(
  blurRadius: 30,
  spreadRadius: 10,
)

Large or numerous shadows can increase rendering cost.

Complex Clipping

Clipping complex shapes may add additional rendering work.

Complex CustomPainter Operations

A painter containing hundreds or thousands of drawing operations per frame can increase raster workload significantly.

Large Animated Areas

Animating a large portion of the screen means more visual content may need to be processed each frame.

---

UI Work vs Raster Work

Flutter performance discussions often separate work happening on the Dart/UI side from work performed by the rasterizer.

Conceptually:

UI work
-----------------
Build
Layout
Some paint preparation


Raster work
-----------------
Rasterize scene
Process graphical operations
Generate pixels

This distinction is extremely useful when analyzing jank.

---

What Is UI Jank?

Suppose your application performs too much work while preparing a frame.

For example:

Heavy build()
     +
Complex state processing
     +
Expensive layout

The UI side may fail to prepare the frame quickly enough.

This can result in a dropped or delayed frame.

---

What Is Raster Jank?

Now imagine your Dart/UI work is reasonably fast.

However, the screen contains:

Multiple blurs
Large shadows
Complex clipping
Large images
Expensive custom painting

The rasterizer may take too long to render the frame.

That is a different performance problem.

Optimizing widget rebuilds alone may not solve it.

---

Understanding the Frame Budget

A display running at 60 Hz attempts to display approximately 60 frames each second.

That gives roughly:

1000 ms ÷ 60
≈ 16.67 ms

per display interval.

For a 120 Hz display:

1000 ms ÷ 120
≈ 8.33 ms

The practical goal is for frame production to keep up with the display’s frame cadence.

When work repeatedly takes too long, users may notice:

Stutter
Dropped frames
Choppy scrolling
Delayed animations
Jank

---

Complete Example of the Pipeline

Suppose you write:

Container(
  width: 200,
  height: 100,
  decoration: BoxDecoration(
    color: Colors.blue,
    borderRadius: BorderRadius.circular(20),
    boxShadow: const [
      BoxShadow(
        blurRadius: 10,
      ),
    ],
  ),
  child: const Center(
    child: Text('Flutter'),
  ),
)

Flutter processes it conceptually like this.

Step 1: Build

Flutter evaluates:

Container
Center
Text

and updates the relevant element/render-object structure.

Step 2: Layout

Flutter determines:

Container = 200 × 100

Center
→ positioned inside Container

Text
→ measured and centered

Step 3: Paint

Flutter generates visual instructions for:

Background
Rounded corners
Shadow
Text

Step 4: Compositing

Flutter prepares the necessary layer/scene information.

Step 5: Raster

The rendering engine converts those instructions into pixels.

Step 6: Display

The resulting frame can be presented on the screen.

So your simple:

Container(...)

ultimately goes through an entire rendering pipeline.

---

Build, Layout, Paint and Raster Compared

Stage	Main Responsibility	Common Performance Problem
Build	Update widget configuration	Excessive or expensive rebuilds
Layout	Calculate sizes and positions	Complex/repeated layout
Paint	Generate drawing commands	Large or unnecessary repaint regions
Compositing	Organize visual layers	Excessive layer complexity
Raster	Convert scene into pixels	Expensive visual effects

This distinction is important because each problem requires a different optimization.

---

Example: Animation Performance Problem

Suppose you have:

AnimatedContainer(
  duration: const Duration(milliseconds: 500),
  width: expanded ? 300 : 100,
  height: 100,
  color: expanded
      ? Colors.blue
      : Colors.red,
)

Several things are changing.

The width changes:

Layout work

The color changes:

Paint work

The animation generates multiple frames:

Repeated frame processing

Depending on the visual effects involved, raster work also occurs for every frame.

Understanding this makes it easier to choose the right optimization.

---

Transform Animation vs Layout Animation

Consider moving a widget by changing its position through layout.

For example:

AnimatedPositioned(
  left: moved ? 200 : 0,
  duration: const Duration(milliseconds: 500),
  child: const FlutterLogo(),
)

Changing layout-related properties can require layout work during the animation.

In some scenarios, using a transform:

Transform.translate(
  offset: Offset(x, 0),
  child: const FlutterLogo(),
)

can avoid changing the child’s layout geometry and instead transform how it is rendered.

That can make transforms attractive for certain animation scenarios.

However, the correct choice should still depend on your UI requirements and profiling results.

---

How RepaintBoundary Fits Into the Pipeline

RepaintBoundary does not primarily optimize Build.

It also does not prevent Layout.

Its purpose is related to painting and compositing.

Build
   ↓
Layout
   ↓
Paint
   ↓
[RepaintBoundary helps here]
   ↓
Compositing
   ↓
Raster

For example:

RepaintBoundary(
  child: AnimatedChart(),
)

can isolate a frequently repainting chart from nearby content.

This is especially useful when:

Child changes frequently
        +
Parent/siblings remain mostly static
        +
Painting surrounding UI is expensive

---

How const Fits Into the Pipeline

const widgets primarily help with widget-tree work.

For example:

const Text('Hello')

Because the configuration is constant, Flutter can reuse the same widget instance in situations where the parent rebuilds.

Therefore:

const
→ Build-side optimization

RepaintBoundary
→ Paint/compositing optimization

They solve different problems.

---

How shouldRepaint Fits Into the Pipeline

When using CustomPainter, implement:

@override
bool shouldRepaint(
  covariant ChartPainter oldDelegate,
) {
  return oldDelegate.data != data;
}

This helps Flutter determine whether the custom painter actually needs to repaint after its delegate changes.

Returning:

true

unnecessarily can lead to extra painting.

Returning:

false

when visual output actually changed can produce incorrect rendering.

The method should accurately represent whether the new painter would produce different visual output.

---

How to Find Build Performance Problems

Flutter DevTools can help identify expensive frame activity.

You should investigate patterns such as:

Large widget subtrees rebuilding frequently
Expensive calculations inside build()
Poorly scoped state updates
Animations rebuilding unnecessary UI
Repeated synchronous work

Avoid heavy computations directly inside:

Widget build(BuildContext context)

For example, doing expensive processing on every build is usually a bad pattern:

@override
Widget build(BuildContext context) {
  final result = performExpensiveCalculation();

  return Text('$result');
}

Move expensive work outside the hot build path where appropriate.

---

How to Find Repaint Problems

During development, Flutter provides repaint debugging tools.

For example:

import 'package:flutter/rendering.dart';

void main() {
  debugRepaintRainbowEnabled = true;

  runApp(
    const MyApp(),
  );
}

When repainting occurs, Flutter visually highlights repaint regions.

If a tiny animation causes a huge region to repeatedly change colors, investigate the repaint structure.

A strategically placed RepaintBoundary may help.

---

How to Find Raster Problems

Use Flutter DevTools in profile mode rather than judging final performance from debug mode.

Run:

flutter run --profile

Then reproduce the performance issue while recording performance information.

Look for expensive frames and determine whether the bottleneck is primarily associated with UI-side frame preparation or rasterization.

For example:

Frame takes too long
       ↓
Check frame timeline
       ↓
UI work high?
       ↓
Investigate build/layout/Dart work

Raster work high?
       ↓
Investigate graphics/rendering work

---

Common Build Performance Mistakes

Avoid patterns such as unnecessarily rebuilding an entire page for a tiny state update.

For example:

setState(() {
  counter++;
});

at a very high level may cause more build work than needed.

Other common issues include:

Heavy calculations in build()
Poor state-management scope
Huge widget subtrees
Unnecessary object creation
Frequently changing inherited state

---

Common Layout Performance Mistakes

Watch for:

Excessive intrinsic measurements
Deeply complicated layout trees
Repeated size changes during animations
Unnecessarily complex constraints
Large dynamically measured content

Do not automatically assume a complicated widget tree is slow, though.

Measure the actual layout cost first.

---

Common Paint Performance Mistakes

Typical problems include:

Large repaint areas
Complex CustomPainter work
Repeated painting of static content
Large decorated regions
Unnecessary visual complexity

Potential solutions include:

RepaintBoundary
Correct shouldRepaint()
Smaller repaint regions
Simpler painting operations

Again, verify the result through profiling.

---

Common Raster Performance Mistakes

Raster-heavy interfaces frequently contain effects such as:

Large blur effects
Multiple shadows
Complex clipping
Large images
Large animated regions
Expensive shader/effect work
Complex custom graphics

If rasterization is the bottleneck, reducing widget rebuilds may have little impact.

Instead, simplify the expensive visual operations.

---

A Better Flutter Performance Workflow

Do not start with random optimizations.

Use this process:

App feels janky
      ↓
Run in Profile Mode
      ↓
Open DevTools
      ↓
Record problematic interaction
      ↓
Find slow frames
      ↓
Identify bottleneck
      ↓
 ┌────────┬────────┬────────┬─────────┐
 Build   Layout    Paint    Raster
   ↓        ↓        ↓         ↓
Fix the actual bottleneck
      ↓
Profile again

This is much more reliable than adding const, RepaintBoundary, caching, or other optimizations everywhere.

---

Practical Optimization Example

Imagine a dashboard containing:

Dashboard
 ├── Profile Header
 ├── Statistics Cards
 ├── Live Chart
 ├── Recent Orders
 └── Background Effects

Scrolling and chart animation feel janky.

Profiling might reveal different causes.

Scenario 1: Build Is Expensive

The entire dashboard rebuilds every time new chart data arrives.

Solution:

Move state closer to chart
Use selective listeners
Use const where appropriate
Avoid expensive work in build()

Scenario 2: Layout Is Expensive

A frequently changing widget continuously changes dimensions.

Solution:

Reduce repeated geometry changes
Simplify layout
Avoid unnecessary intrinsic measurement

Scenario 3: Paint Is Expensive

The animated chart causes a large section of the dashboard to repaint.

Potential solution:

RepaintBoundary(
  child: LiveChart(),
)

Scenario 4: Raster Is Expensive

The dashboard uses several large blurs, shadows, clips, and complex graphics.

Solution:

Reduce expensive visual effects
Optimize images
Simplify graphics
Reduce large animated areas

Same symptom:

Jank

Different causes:

Build
Layout
Paint
Raster

That is why understanding the rendering pipeline matters.

---

Frequently Asked Questions

What is the Build phase in Flutter?

The Build phase evaluates widget configurations and updates the corresponding element/render-object structure when required.

What is the Layout phase?

The Layout phase calculates the sizes and positions of render objects according to Flutter’s constraint-based layout system.

Remember:

Constraints go down, sizes go up, and parents set positions.

What is the Paint phase?

The Paint phase generates drawing commands describing how render objects should visually appear.

What is rasterization in Flutter?

Rasterization converts the prepared scene and drawing operations into pixels that can ultimately be displayed on the device.

Is rebuild the same as repaint?

No.

A rebuild updates widget configuration, while repainting deals with visual drawing work. They are different stages.

Does setState repaint the whole screen?

Not necessarily.

setState() marks the associated state for rebuilding. What subsequently requires layout or painting depends on what actually changed and the render tree.

Does RepaintBoundary prevent rebuilds?

No.

RepaintBoundary primarily isolates painting. It is not a rebuild optimization.

Should I optimize Build or Raster first?

Profile first.

If UI-side work is expensive, investigate build, layout, and synchronous Dart work. If raster work is expensive, investigate graphics, effects, images, painting, and other rendering costs.

---

Final Thoughts

Understanding Flutter performance becomes much easier when you stop treating every slow frame as a “rebuild problem.”

Flutter’s rendering process can be thought of as:

Widget Configuration
        ↓
Build
        ↓
Layout
        ↓
Paint
        ↓
Compositing
        ↓
Rasterization
        ↓
Pixels

Each stage has a different responsibility.

Build determines and updates UI configuration.

Layout determines size and position.

Paint creates visual drawing instructions.

Compositing organizes visual content into a scene and layers where needed.

Rasterization converts that scene into pixels for display.

Most importantly, different performance problems require different solutions:

Too many expensive rebuilds
→ Optimize state and widget structure

Expensive layout
→ Simplify layout calculations

Unnecessary repainting
→ Optimize painting and consider RepaintBoundary

Raster jank
→ Reduce expensive graphics and visual effects

When a Flutter application becomes janky, avoid guessing.

Run the application in profile mode, inspect the problematic frames with Flutter DevTools, identify whether the bottleneck is Build, Layout, Paint, or Raster, make a targeted optimization, and profile again.

That approach produces much more reliable performance improvements than applying optimization techniques everywhere.