Improve your Flutter Apps performance with a RepaintBoundary 

Fantastic!

Thanks for the nice words :)

You're welcome

Thanks a lot for the kind words. Glad you found it useful!

Yup. That's bad. It's a useful one. But not a well known one. Hopefully flutter will make repaintBoundary *the widget of the week*

Great! That conditioned thinking is not wrong, sepending on how widgets are grouped together (and rebuilt) then definitely, it can have a performance impact. Painting is just one part, and generally we shouldn't be too concerned about the cost. Only use a repaint boundary if you see performance issues in certain areas that do heavy painting. There are a lot of other performance considerations as well and I'll be making more videos on it!

@@FunwithFlutter Ohh... Cool. That's why it's called *repaint* Boundary. It's only a boundary for painting tasks. Which implies, I will split expensive widgets in some occasions. Thanks mate. Happy coding ☺️

Thanks!🙃

Thanks!

Glad you think so!

The code is! I'm busy updating/migrating the code snippets and other examples throughout the course. The vids are not yet updated to null safety :( Glad that this vid helped though!

@@FunwithFlutter i'm looking to buying it, i just need some money ;). And once again, thanks for this great content =D

Hmm, can you tell me what you tried? Slivers are used in CustomScrollView, and just like ListView it should manage the RepaintBoundary for you, so no need to add an extra RepaintBoundary. In the video I have an example showing a ListView. Because the ListView will always repaint independently from whatever is outside of the list, that's why they have a RepaintBoundary by default - same with CustomScrollView (Slivers). If you enable the debugRepaintRainbowEnabled flag and scroll in a CustomScrollView (or ListView) you will see the different colored areas that are grouped (painted) together, showing where the layers are being cached for quicker scrolling. You'll also see the colors changing when you scroll back, meaning they are not being cached and the list is deciding to repaint them. If you want to increase the caching then you can play around with the cacheExtent attribute in a CustomScrollView. If the cacheExtent is high enough then Flutter will cache the previous slivers that were scrolled into view for further up the list, so now if you scroll back the colors may not have changed if those layers are still cached. That all said, I only minimally understand how lists and grids are optimally rendered. "Infinite scrolling lists are notoriously difficult for toolkits" - quoting the docs. And there's a ton that goes into it to make it performant. I'd say trust the Google engineers on this and just use the lists like normal, while playing around with the attributes the lists expose (such as cacheExtent) to tweak it the way you like.

@@FunwithFlutter Yeah, I missed the point ScrollView has RepaintBoundary by default. Very clear explaination. Awesome, thank you so much.

@@FunwithFlutter Coooooool!!! How did you know that?? I want to improve my flutter skills like yours. What do you recommend?

Technically yes, but this isn't a problem. Skia/Flutter does this extremely fast and this is definitely not something you have to worry about. As Flutter developers it's more important for us to manage the Widget lifecycle and avoid unnecessary rebuilds (keys, constants, small build methods) - as this allows the Flutter Framework to be efficient in taking our widgets and updating what should render on the screen. But Painting is different to the Widgets rebuilding, everything inside a RepaintBoundary will be repainted when something in that RepaintBoundary needs to be repainted. Not a problem most of the time, as Painting normal widgets are not expensive. Here is a long answer that I gave to a similar question if you want more info: The long answer: In Flutter you have Widgets, Elements and RenderObjects. Widgets are inexpensive and get rebuilt all the time, Elements keep track of widgets and their positions in the Tree (and their associated RenderObjects). The RenderObjects are responsible for layout, painting, etc. Flutter is very efficient in only rebuilding the part of the Tree that need updating (basically when the immutable widgets change). It also won't perform unnecessary work when it's not needed. This is mostly managed for you and you do not need to care, but as Flutter developers we can do things to guide the framework to manage the life cycle efficiently (keys, constants, small build methods, etc). Painting works differently though. When one widgets changes (even if it's in a separate build method) then Flutter/Skia will repaint everything that is within the same display list (RepaintBoundary). There are many different phases/computations that happen from widget -> to finally displaying the widget on screen. Repainting everything on screen is not necessarily a problem and under most circumstances this will happen fast. BUT, we have the OPTION to tell Flutter that this part of the widget tree should be treated independently from another part (in terms of Painting). If you're just laying out text then there is no real need as it's inexpensive to paint, but if you're doing crazier things or if you have a widget with an expensive paint operation then it makes sense to wrap it in a RepaintBoundary. Depending on the platform you're targeting you may have a different approach as well. On desktop you have more memory which frees you up to be able to cache more images (display lists) instead of repainting them, so maybe using more Repaint Boundaries. But there is not need to overuse them. ListView is a great example of using a RepaintBoundary, as whatever painting happens in a ListView is independent of other painting on the screen.

Yes please

Definitely not. Something I explain in way more detail in the course. There have also been similar questions to this where I provide a detailed answer. Painting all of the widgets to screen happens extremely fast and under most circumstance we should not worry about performance. Only seek to improve performance when it's an issue or when you believe it can be improved. Wrapping everything in a RepaintBoundary will result in higher memory use as more parts are being cached, and painting is generally cheap. Only do it for widgets with expensive paint operations or when widgets repainting should have no effect on other part of your tree (for example, a ListView - which has a repaint boundary by default). Here is a long answer I gave to similar questions: The long answer: In Flutter you have Widgets, Elements and RenderObjects. Widgets are inexpensive and get rebuilt all the time, Elements keep track of widgets and their positions in the Tree (and their associated RenderObjects). The RenderObjects are responsible for layout, painting, etc. Flutter is very efficient in only rebuilding the part of the Tree that need updating (basically when the immutable widgets change). It also won't perform unnecessary work when it's not needed. This is mostly managed for you and you do not need to care, but as Flutter developers we can do things to guide the framework to manage the life cycle efficiently (keys, constants, small build methods, etc). Painting works differently though. When one widgets changes (even if it's in a separate build method) then Flutter/Skia will repaint everything that is within the same display list (RepaintBoundary). There are many different phases/computations that happen from widget -> to finally displaying the widget on screen. Repainting everything on screen is not necessarily a problem and under most circumstances this will happen fast. BUT, we have the OPTION to tell Flutter that this part of the widget tree should be treated independently from another part (in terms of Painting). If you're just laying out text then there is no real need as it's inexpensive to paint, but if you're doing crazier things or if you have a widget with an expensive paint operation then it makes sense to wrap it in a RepaintBoundary. Depending on the platform you're targeting you may have a different approach as well. On desktop you have more memory which frees you up to be able to cache more images (display lists) instead of repainting them, so maybe using more Repaint Boundaries. But there is not need to overuse them. ListView is a great example of using a RepaintBoundary, as whatever painting happens in a ListView is independent of other painting on the screen.

Sounds like you have some logic that is still being triggered that’s causing the background work. Best way would be to use Flutter DevTools and profile the application. That will show you what methods are being called and allow you to find the source.

Not too sure what you mean. const will make sure that the widget doesn't rebuild unnecessarily, however painting is different. Even if a widget is not rebuilt it will still be repainted within the same repaint boundary when another widget causes a repaint. Similar questions from other people provide a more detailed answer

@@FunwithFlutter yes. thank you !

Oof no idea sorry

Flutter will cache an image the first time it is rendered in app. Not sure how this is persisted (session or app). I think app. But not sure. More info here: flutter.dev/docs/perf/rendering/ui-performance#checking-for-non-cached-images. You can also take a look at flutter.dev/docs/perf/rendering/shader which will allow you to "warm up" the shader. Which will allow you to get smooth performance from the first time the app is opened. Obviously only worry about this if you need to. Under most circumstances you should experience performance issues in Flutter

@@FunwithFlutter the point is if it is cashed during compile time as a static const. if i create a repaintedBordery in the login screen maybe if the user loged in will never use this screen again until signing out. So if it will cached in the cache memory in this case will be a useless.

@@FunwithFlutter thanks a lot for docs, i will read all of them.

Good question. Guess that is something I do not explain well in this video, but in the course there are dedicated videos addressing this, and this video builds on that. To quickly answer your question: What you're describing is efficient from a Widget rebuild and layout perspective. Using Consumers/Selectors will result in only parts of the widget tree rebuilding, and allows the Flutter framework to be efficient in what it determines to need updating (creating RenderObjects from Widgets). The long answer: In Flutter you have Widgets, Elements and RenderObjects. Widgets are inexpensive and get rebuilt all the time, Elements keep track of widgets and their positions in the Tree (and their associated RenderObjects). The RenderObjects are responsible for layout, painting, etc. Flutter is very efficient in only rebuilding the part of the Tree that need updating (basically when the immutable widgets change). It also won't perform unnecessary work when it's not needed. This is mostly managed for you and you do not need to care, but as Flutter developers we can do things to guide the framework to manage the life cycle efficiently (keys, constants, small build methods, etc). Painting works differently though. When one widgets changes (even if it's in a separate build method) then Flutter/Skia will repaint everything that is within the same display list (RepaintBoundary). There are many different phases/computations that happen from widget -> to finally displaying the widget on screen. Repainting everything on screen is not necessarily a problem and under most circumstances this will happen fast. BUT, we have the OPTION to tell Flutter that this part of the widget tree should be treated independently from another part (in terms of Painting). If you're just laying out text then there is no real need as it's inexpensive to paint, but if you're doing crazier things or if you have a widget with an expensive paint operation then it makes sense to wrap it in a RepaintBoundary. Depending on the platform you're targeting you may have a different approach as well. On desktop you have more memory which frees you up to be able to cache more images (display lists) instead of repainting them, so maybe using more Repaint Boundaries. But there is not need to overuse them. ListView is a great example of using a RepaintBoundary, as whatever painting happens in a ListView is independent of other painting on the screen.

Fun with Flutter sounds like I should take the course to really dive deeper into flutter! I’m comfortable with all state managements and flutter concepts but this in-depth understanding of code optimisation is something I should learn :) Is there a link to the course?

Totally worth it to do a deep dive into the inner workings. The link: bit.ly/funwithcourse with discount applied. Go directly to Section 7 if you only care about the performance part!

Nice