Flutter's Rendering Pipeline
Why Stack Overflow recommends it
Stack Overflow users link it when answering Flutter questions about layout constraints, repaint boundaries, widget nesting and rendering performance, since it explains the mechanics behind those behaviors.
Recommended by 4 people across 6 different months, 2017 to 2021.
What it is
A 54-minute Google Tech Talk by Adam Barth, recorded in May 2016, on how Flutter turns a tree of widgets into pixels at 60 Hz. It walks through the stages of the pipeline: layout, painting, compositing and rasterization.
What people said
Recommends Rémi Rousselet · 2017-10 · Stack Overflow · on “How to ensure my CustomPaint widget painting is stored in the raster cache?”
It's a specificity of Flutter. We are not in React, where "Components" are repainted only when their state/props change. In Flutter, every time a widget has to repaint the whole tree will too. Usually, this is not a problem and fairly fast. But in some cases (such as yours), you don't want that. And this is where a fairly undocumented but important widget appears! RepaintBoundary There's an excellent talk about how Flutter's rendering pipeline works, here: [this video] But in short, consider RepaintBoundary as what tells Flutter to split the painting operation into different parts. Anyway, the solution ? Wrap your Expensive widget in a RepaintBoundary . And suddenly you get 60 FPS. new RepaintBou
Recommends Marcel · 2018-10 · Stack Overflow · on “Defining widgets inside initState or class constructors rather than build?”
TL;DR : Don't. First, let's see what Googler and Flutter engineer Matt Sullivan has to say about this topic [LINK] : With Flutter creating and destroying objects with great frequency, should developers take steps to limit this behavior? It’s not uncommon to see new Flutter developers create references to widgets they know will not change over time, and place them in state so that they won’t be destroyed and rebuilt. Don’t do this. In order to understand why this is a bad idea, you first of all need to understand that Widget s do very little . Because they usually just compose other Widget s or instantiate RenderObject s, they don't do the actual rendering; all the heavy lifting is done by Re
Recommends Marcel · 2018-10 · Stack Overflow · on “How to place an image below a listview in flutter?”
Ooh cool, I didn't know `List`s override the `+` operator... good to know. And yes, while you can compose widgets very flexibly in Flutter, `ListView`s are not intended to be used as direct children to `Column`s. The reason is that `ListView`s take all the available space they can and `Column`s provide each child with infinite height constraints as a way to communicate with them to be as small as possible. For more information, have a look at this interesting Google Tech Talk about Flutter's rendering pipeline [this video] .
Recommends Marcel · 2018-12 · Stack Overflow · on “Autoresize Text to fit in Container vertically”
TL;DR: Your AutoSizeText widget is probably provided with unbounded constraints. This can be the case if it's wrapped in a Column , Row , ListView or something similar. To counter this issue, wrap it in an Expanded widget. In order to answer that question, we need to understand how Flutter performs the layout. Basically, the top widget's height and width (called its "dimensions") are requested by the framework, which provides a min and max width and height (called "constraints"). In order to calculate its dimensions, the widgets ask their children what dimensions they want to have based on some constraints. So, every widget gets told constraints and returns concrete dimensions within these c
Recommends Marcel · 2019-01 · Stack Overflow · on “Is it bad to have a lot of nested widgets with Flutter?”
TL;DR: Deeply nesting single-purpose widgets in Flutter is recommended. There are fundamental differences in how Android and Flutter render view elements (aka widgets or views). In Android, there are relatively few, complex views that inherit each other. Each and every view provides a huge API surface, including stuff like padding, margin, colors etc. Flutter, on the other hand, favors composition over inheritance . Most widgets exist for a single purpose only and are very lightweight. That means you need to nest widgets more deeply to achieve the same effects, but because their layout and rendering logic is easier, the rendering is typically faster. For example, there's a Padding widget tha
Recommends Kirill Matrosov · 2020-03 · Stack Overflow · on “How to get width of Text widget before it has rendered”
You cant get these sizes. In widgets you set constraints but final sizes we have after layout is ready. And then we can read them with MediaQuery [LINK] . From Google video [this video] you can get more information
Recommends mjhd · 2021-11 · Stack Overflow · on “What is the meaning of "width-in-height-out"?”
Here's very interesting video: [this video] In this video, the speaker says something like "Width-in Height-out is a common layout paradigm in Web (browser). You set the width constraint to be tight and set the height constraint to be loose. The parent specifies the width, then the child determines the height".
Cites user1462442 · 2018-10 · Stack Overflow · on “Performance implications of FittedBox?”
I wouldn't worry too much about performance Flutter is designed to use simple algorithms to achieve 60 fps 1 pass layout composition O(n) Separated layout and painting Children tell the parent to invalidate the subtrees etc. [LINK] [LINK] [this video] [LINK] I cannot say the all the performance implications but it shouldnt matter.