Defining updating theme causes lot of rebuilds

If you define textButtonTheme with TextButton.styleFrom in the MaterialApp's theme property, there will be a lot of unnecessary (?) rebuilds.
Also Theme.of(context) must be used to reproduce this bug.

You can see on the attached pictures that adding TextButton.styleFrom(primary: Colors.red), will cause 12 times more rebuilds than with the code without it.

If I remove Theme.of(context) from the Scaffold then it only gets rebuilt once.

note: I forced a rebuild with cmd+s (hot reload). In the actual application, I'm using a BlocBuilder and this causes the initial rebuild.

I know that flutter can call rebuild whenever it wants and I should calculate with it but rebuilding it 12 times is obviously noticeable (there is a little flickering in the elements in my actual app)

Steps to Reproduce

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
        theme: ThemeData(
            textButtonTheme: TextButtonThemeData(
          style: TextButton.styleFrom(),
        )),
        debugShowCheckedModeBanner: false,
        home: Home());
  }
}

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    print('Home build');
    return Scaffold(
      backgroundColor: Theme.of(context).primaryColor,
    );
  }
}

channel: stable
version: 2.2.3
macOS 11.5.2
simulator: iPhone 8 (iOS 14.5)

Expected results:

Actual results:

Logs

info • Avoid `print` calls in production code • example/lib/main.dart:21:5 • avoid_print

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.2.3, on macOS 11.5.2 20G95 darwin-x64, locale en-JP)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 3.5)
[✓] VS Code (version 1.59.1)
[✓] Connected device (2 available)

• No issues found!

@hbali

Hi @hbali, thanks for filing the issue.

Using hot-reload to force rebuild the app I was able to confirm your results, however, I wanted to know if this had anything to do with state rebuilds so I modified your sample code a little but after the modification I'm unable to reproduce it.

Perhaps this could be a different issue?

Kindly try out my example to confirm for yourself.

updated code sample

import 'dart:async';

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

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData(
        textButtonTheme: TextButtonThemeData(
          style: TextButton.styleFrom(primary: Colors.red),
        ),
      ),
      debugShowCheckedModeBanner: false,
      home: Home(),
    );
  }
}

class Home extends StatefulWidget {
  @override
  _HomeState createState() => _HomeState();
}

class _HomeState extends State<Home> {
  @override
  initState() {
    super.initState();
    SchedulerBinding.instance?.addPostFrameCallback((_) {
      Timer.periodic(const Duration(seconds: 5), (timer) {
        setState(() {
          print('${timer.tick}');
        });
      });
    });
  }

  @override
  Widget build(BuildContext context) {
    print('Home build');
    return Scaffold(
      backgroundColor: Theme.of(context).primaryColor,
    );
  }
}

logs(timer was running in the background)

`Notice the home build prints only once after each ticker print`

@danagbemava-nc

@danagbemava-nc

Thank you for your response!

I copied your code and the result is the same as yours, build only happens once per setState.

I modified the code a bit and moved the rebuild outside the Home widget (so the MaterialApp also gets rebuilt). This is closer to my actual app implementation since the issue occurs when I change the color theme of the app → thus I need to rebuild the whole MaterialApp

This way, the problem occurs again.

import 'dart:async';

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

void main() => runApp(MyApp());

class MyApp extends StatefulWidget {
  @override
  _MyAppState createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  @override
  void initState() {
    super.initState();
    SchedulerBinding.instance?.addPostFrameCallback((_) {
      Timer.periodic(const Duration(seconds: 5), (timer) {
        setState(() {
          print('${timer.tick}');
        });
      });
    });
  }

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
        theme: ThemeData(
            primaryColor: Colors.red,
            textButtonTheme: TextButtonThemeData(
              style: TextButton.styleFrom(primary: Colors.red),
            )),
        debugShowCheckedModeBanner: false,
        home: Home());
  }
}

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    print('Home rebuild');
    return Scaffold(
      backgroundColor: Theme.of(context).primaryColor,
    );
  }
}

Logs

After some more investigation:

the same problem occurs if I define cupertinoOverrideTheme in the ThemeData. I wanted to change the default purple color of the CupertinoActionSheet text (why is it purple, why isn't it systemBlue?) and numerous rebuilds happened as soon as I defined the property.

Probably there are more properties in ThemeData that causes these mysterious rebuilds

I can reproduce this issue on master and stable with the source in this comment.

flutter doctor -v

[✓] Flutter (Channel master, 2.6.0-1.0.pre.111, on macOS 11.5.1 20G80
    darwin-arm, locale en-GB)
    • Flutter version 2.6.0-1.0.pre.111 at /Users/nexus/dev/sdks/flutters
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 965bd1ff40 (11 hours ago), 2021-08-29 23:41:02 -0400
    • Engine revision f4a380f3e5
    • Dart version 2.15.0 (build 2.15.0-65.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.5.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • CocoaPods version 1.10.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.59.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.25.0

[✓] Connected device (5 available)
    • M2007J20CG (mobile)    • 5dd3be00                             •
      android-arm64  • Android 11 (API 30)
    • Nexus’ IPhone (mobile) • 00008020-001875E83A38002E            • ios
      • iOS 14.6 18F72
    • iPhone 12 (mobile)     • F2592D43-5FE3-46BB-8A2B-A38BA468DCE9 • ios
      • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • macOS (desktop)        • macos                                •
      darwin-arm64   • macOS 11.5.1 20G80 darwin-arm
    • Chrome (web)           • chrome                               •
      web-javascript • Google Chrome 92.0.4515.159

• No issues found!

[✓] Flutter (Channel stable, 2.2.3, on macOS 11.5.1 20G80 darwin-arm, locale
    en-GB)
    • Flutter version 2.2.3 at /Users/nexus/dev/sdks/flutter
    • Framework revision f4abaa0735 (9 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/nexus/Library/Android/sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.10.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7249189)

[✓] VS Code (version 1.59.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.25.0

[✓] Connected device (5 available)
    • M2007J20CG (mobile)    • 5dd3be00                             •
      android-arm64  • Android 11 (API 30)
    • Nexus’ IPhone (mobile) • 00008020-001875E83A38002E            • ios
      • iOS 14.6
    • iPhone 12 (mobile)     • F2592D43-5FE3-46BB-8A2B-A38BA468DCE9 • ios
      • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • macOS (desktop)        • macos                                •
      darwin-arm64   • macOS 11.5.1 20G80 darwin-arm
    • Chrome (web)           • chrome                               •
      web-javascript • Google Chrome 92.0.4515.159

• No issues found!

log.txt

This is not just TextButtonTheme but any theme updates cause a lot of rebuilds. I think this is expected since the theme contains many visual changes, any modifications to the theme would require app rebuilds.

minimal code sample

import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
        theme: ThemeData(
          toggleButtonsTheme: ToggleButtonsThemeData(
            color: Colors.red,
          )
          //   textButtonTheme: TextButtonThemeData(
          // style: ButtonStyle(
          //   foregroundColor: MaterialStateProperty.all<Color>(Colors.red),
          // ),
          // style: TextButton.styleFrom(primary: Colors.red),
        ),
        debugShowCheckedModeBanner: false,
        home: Home());
  }
}

class Home extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    print('Home build');
    return Scaffold(
      backgroundColor: Theme.of(context).primaryColor,
    );
  }
}

Results

7
flutter: Home build
Reloaded 1 of 584 libraries in 236ms.
11
flutter: Home build

Keeping the issue open in case anyone face problems

I think the reason behind this is lerp methods which makes the theme changing animations smoother

@raghavendra-k-j

@raghavendra-k-j yes it is a correct observation that all values in ThemeData are changed via a lerp animation. So if you observe the rebuild of widgets that are affected by any changed property value in ThemeData, you will see a lot of rebuilds of those widgets as the Theme linearly animates through those values to the new target value. This is normal and expected behavior.

However, the problem is that as soon as you use any component theme that contains a MaterialStateProperty (now in master WidgetStateProperty) that is not null, ie defined to some custom theme value, the Theme will lerp animate and rebuild all widgets, even if there is no value change on ThemeData.

This happens because using MaterialStateProperty breaks object equality, so the same ThemeData is no longer equal and everything is animated and rebuilt anyway, even if nothing was changed and nothing should have been rebuilt.

This is imo a real and severe issue with ThemeData and the used MaterialStateProperty solution.

Another sample to demo the issue

Consider this "a bit" more involved sample:

import 'package:flutter/material.dart';

void main() {
  final ThemeController themeController = ThemeController();
  runApp(MyApp(themeController: themeController));
}

class MyApp extends StatelessWidget {
  const MyApp({super.key, required this.themeController});
  final ThemeController themeController;

  @override
  Widget build(BuildContext context) {
    debugPrint('#build MyApp');
    return ListenableBuilder(
        listenable: themeController,
        builder: (BuildContext context, Widget? child) {
          debugPrint('#build MaterialApp');
          return MaterialApp(
            title: 'Flutter Demo',
            theme:
                appLightTheme(appBarElevation: themeController.appBarElevation),
            home: Builder(
              builder: (BuildContext context) {
                debugPrint("#build Scaffold");
                return Scaffold(
                  appBar: AppBar(
                    title: const Text('Flutter Demo'),
                  ),
                  backgroundColor: Theme.of(context).canvasColor,
                  body: BodyContent(themeController: themeController),
                );
              },
            ),
          );
        });
  }
}

class BodyContent extends StatelessWidget {
  const BodyContent({super.key, required this.themeController});
  final ThemeController themeController;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        const SizedBox(height: 20),
        SwitchListTile(
          title: const Text('Elevate AppBar'),
          onChanged: (bool value) {
            if (value) {
              themeController.setAppBarElevation(4);
            } else {
              themeController.setAppBarElevation(0);
            }
          },
          value: themeController.appBarElevation > 0,
        ),
        TextButton(
            onPressed: () {
              themeController.triggerRebuild();
            },
            child: const Text('Trigger Rebuild')),
      ],
    );
  }
}

class ThemeController with ChangeNotifier {
  ThemeController();
  double _appBarElevation = 0;

  get appBarElevation => _appBarElevation;
  void setAppBarElevation(double elevation) {
    _appBarElevation = elevation;
    notifyListeners();
  }

  void triggerRebuild() {
    notifyListeners();
  }
}

ThemeData appLightTheme({double appBarElevation = 0}) => ThemeData(
      appBarTheme: AppBarTheme(
        elevation: appBarElevation,
        shadowColor: Colors.black,
        // Adding this will make the elevation tint color change animate too.
        shape: const RoundedRectangleBorder(),
      ),
      textButtonTheme: TextButtonThemeData(
        style: TextButton.styleFrom(elevation: 1),
      ),
    );

On first build we see this:

We see the 3 builds that the framework triggers (I wish that was just once too, but there are bunch of wrappers that triggers it 3 times).

Then many Scaffold rebuilds as the theme change was animated. But was there really something to lerp animate? Let's look at it in more detail.

Elevate AppBar

Let's start by elevating the AppBar:

Screen.Recording.2024-04-06.at.16.38.34.mov

The MaterialApp rebuilds once, and Scaffold many times as the AppBar elevates and changes style via an animation. The elevation tint color is animated, as is the appearance of the shadow under it. This is all expected and as it should be

Note

In the AppBarTheme the shape: const RoundedRectangleBorder() is needed to make the change in elevation tint color animate as it should. That this is needed is due to a performance optimization that is made on Material widget. See issue #131042 for more info.

Trigger rebuild - Take 1

Next let us just push the button to trigger a rebuild, notifying listeners that the theme controller has changed and thus also the theme:

Screen.Recording.2024-04-06.at.16.59.52.mov

We get the same expected rebuild once of MaterialApp, but Scaffold was built many times, even if nothing in it changed. This is bad, but why did it happen?

It happened because ThemeData object value equality is broken, because we are using a MaterialStateProperty that contain callback functions.

In our ThemeData the styleFrom will define a custom MaterialStateProperty for our AppBarTheme in ThemeData and this kills value equality of ThemeData.

      textButtonTheme: TextButtonThemeData(
        style: TextButton.styleFrom(elevation: 1),
      ),

So the equality checks for rebuilding ThemeData no longer works correctly, due to the callback functions in it.

Trigger rebuild - Take 2

To demo what happens when we do not have any custom MaterialStateProperty defined anywhere in our ThemeData, just remove or comment the textButtonTheme lines in the example theme:

ThemeData appLightTheme({double appBarElevation = 0}) => ThemeData(
      appBarTheme: AppBarTheme(
        elevation: appBarElevation,
        shadowColor: Colors.black,
        // Adding this will make the elevation tint color change animate too.
        shape: const RoundedRectangleBorder(),
      ),
      // textButtonTheme: TextButtonThemeData(
      //   style: TextButton.styleFrom(elevation: 1),
      // ),
    );

Again, let's start with a fresh build, we see that it has the 3 builds by the SDK as before, plus once for our theme change, but now also only once for the Scaffold, no animation rebuild!! This is already better and what we would have expected for the start of the above examples too.

Now again just trigger the rebuild:

Screen.Recording.2024-04-06.at.17.11.12.mov

And now we get the expected behavior, the MaterialApp rebuild is as ordered triggered once, but also the Scaffold was only rebuilt once, as it should have been, since there was nothing changed in it that needed to be animated. The value of the new ThemeData was identical to the previous one, so nothing to animate. However, as shown above earlier, as soon as we have and use any component theme that defines any MaterialStatePorperty the object equality is broken and we get all these extra rebuilds. Feel free to try with any other MaterialStatePorperty in any component sub theme in ThemeData, and you will observe the same extra rebuild behavior.

This is imo a bad when you are using custom component themes that contain MaterialStatePorperty, and any serious custom theme will need a lot of them.

This is caused by the current SDK design. I don't know of any workaround or fix to this rebuild issue.

In my case, I use GoRouter redirect, also I have a text field and one of my widget in the screen is using MediaQuery to get the screen size. Every time I touch the text field, my material app is rebuilt. It causes the flicker on the screen (because every time material app rebuild, it will call the go router navigation), the only way to fix it is removing my material app theme data (it also uses MediaQuery to check the platform).

When setting themeMode: ThemeMode.system, on iOS, entering and exiting the app background will also lead to rebuilding, causing screen flickering issues.

void main() async {
  print("main ");
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    print("myapp ");
    return MaterialApp(
      title: "Application",
      themeMode:ThemeMode.system,
      // theme: AppTheme.lightTheme,
      // darkTheme: AppTheme.darkTheme,
        theme: ThemeData.light(),
        darkTheme: ThemeData.dark(),
      home: HomeView()
    );
  }
}

class HomeView extends StatelessWidget {
  const HomeView({Key? key}) : super(key: key);

  Widget test1(context){

    // var data = Theme.of(context).brightness;
    print("-------test1 has been called------");
    // print("Theme.of(context).brightness ${ data}");
    return Container(
      color: Theme.of(context)
          .primaryColor,
      height: 200,
      width: 200,
      child: Text("123"),
    );
  }

  @override
  Widget build(BuildContext context) {
    print("home build");
    return Scaffold(
      resizeToAvoidBottomInset: false,
      body: ListView(
        children: [
          TextField(),
          test1(context),

        ],
      ),
    );
  }
}

Console Output Results：

flutter: home build
flutter: -------test1 has been called------
flutter: home build
flutter: -------test1 has been called------
flutter: home build
flutter: -------test1 has been called------
flutter: home build
flutter: -------test1 has been called------

When the app enters the background, it will print once
When the app enters the foreground from the background, it will print once.

This is the question I asked before
#142890

@nate-thegrate

I just discovered WidgetStateProperty.fromMap, which was recently added in #146043. Any idea if that works around this performance problem? I guess @nate-thegrate probably wasn't thinking of this performance problem when he wrote it, but even if it doesn't fix the problem out of the box, I think we could theoretically do it by adding a deep equality check to WidgetStateProperties created with fromMap.

It's been very exciting to finally land the WidgetState mapping PR and talk about it here and in the recent design doc :)

Parsing the map in that constructor is something that hadn't even crossed my mind, but I bet it would prevent a lot of rebuilding (though the operators could make that process a bit more convoluted).

It would be a huge challenge, but maybe the most effective way to optimize rebuilds would be transitioning the Theme widget to use an InheritedModel.
MediaQuery uses a private enum type for its dependencies, but Theme could use an API that stores information for making high-precision queries (similar to what provider/riverpod/bloc already have), so we only trigger a rebuild when the query output changes.

I expect over the coming months we can drastically reduce the number of rebuilds caused by Theme.of(context) calls.

Until then, if your theme data includes something like TextButton.styleFrom() that isn't optimized for equality checks, it's probably best to assume that any time the MaterialApp widget rebuilds, it's going to trigger an AnimatedTheme transition.

An easy fix is to set a zero duration for themeAnimationDuration (though obviously there wouldn't be a nice animation even when something does change).

Perhaps something like themeAnimationDuration: kDebugMode ? Duration.zero : Durations.short4 would be ideal.

un-break `ThemeData` equality (#154695)

@nate-thegrate

This issue is assigned to @nate-thegrate but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

The original issue comment showed that TextButton.styleFrom() was ruining the theme data equality check, and fortunately that bug is now fixed.

For anyone experiencing a related problem: feel free to open another issue!

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

Navigation Menu

Repository navigation

Defining updating theme causes lot of rebuilds #89127

Steps to Reproduce

Results

10 remaining items

Another sample to demo the issue

Elevate AppBar

Trigger rebuild - Take 1

Trigger rebuild - Take 2

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Defining updating theme causes lot of rebuilds #89127

Description

Steps to Reproduce

Activity

danagbemava-nc commented on Aug 30, 2021

hbali commented on Aug 30, 2021

hbali commented on Aug 30, 2021

danagbemava-nc commented on Aug 30, 2021

TahaTesser commented on Mar 24, 2022

Results

10 remaining items

raghavendra-k-j commented on Apr 6, 2024

rydmike commented on Apr 6, 2024

Another sample to demo the issue

Elevate AppBar

Trigger rebuild - Take 1

Trigger rebuild - Take 2

HuynhThien82 commented on May 8, 2024

disonwei commented on May 12, 2024

justinmc commented on Aug 27, 2024

nate-thegrate commented on Aug 27, 2024

flutter-triage-bot commented on Jan 10, 2025

nate-thegrate commented on Jan 10, 2025

github-actions commented on Jan 28, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions