This is by far the best explanation about how Flutter render the UI. So, the secret of its performance is not only the Skia but also the application architecture and the amazing reuse of render objects. This is an outstanding work the Flutter team and community have made.
It's almost the same architecture as QT Quick. Only with different words. QML is a markup language that describes your UI, then you have a node of QQuickitems, and QSGNodes (which is the RenderObject here). And then with QT Quick it goes to OpenGL for fast rendering. It also only updates what changes, and doesn't change the widget. It's also super performant just like Flutter. And was here before. Have you ever been in a Tesla Model S or 3 or any Tesla? This whole UI = QT Quick. QT uses QML+Javascript on top. Where Flutter uses Dart (For both markup & scripting) Did you really think this is new technology? They just took that idea, and copied it... And for Skia, QT uses Qpainter which both have similar backends(for example OpenGL).
I've been working on a passion project written in Flutter for quite a while. I've gained understanding of how it works under the hood by reading source code, but I've always had gaps and questions. In 26 minutes, Matt and Andrew taught me more about the framework than I've learned on my own in all that time. I want to thank Matt, Andrew, and the entire Flutter team for producing and publishing these instructional videos. The entire Flutter community is better for it.
This is a much needed foundational explanation! Thank you for taking the time to create it! In my beginner brain, it sounds like they are saying, well, just use the Widget tree and don't care if you duplicate stuff, because we will figure how that stuff is different in the Element tree for you and tell the RenderObject tree if anything needs to be done. So just concentrate on Widgets and "forget" about the other stuff.
@Flutter team: The video starts by explaining the solution, without explaining the actual problem which the architecture is supposed to solve, and what were the alternative architectures, and why this particular architecture was chosen by the flutter team. Would be enlightening, if you can make a video on that.
This video explains how widget replacement is performed, but what happens if I insert a widget into the tree? If I have tree A->B->C->D and insert widget E (say, a container) like so: A->E->B->C->D, how will Flutter react when it reaches widget E? Will it destroy the tree and widgets, elements, and render objects of "B, C, and D", or simply 'unlink' them, but keep them around in memory, and search through that pile of widgets on the side each time as it continues building the widget tree? Would that be facilitated by the widget keys, similar to the 'canUpdate' method? Then, does it clear that memory pile after finishing the whole tree update? If anyone knows a good resource for further explanation, could they share?
so, widgets are like typed Props (except they define what "component" to use) and Elements are like Components and the rendering part is just different... (when comparing it to React)
I don't understand that video :-( ! I know, how to use flutter, i know how games normally work, know many ways to manage the states in flutter and dart, but i dont't understand, how flutter really works. I.E. I can Not say, when flutter redraws my widgtes. Please make another video for that ;-)
I agree the video is not complete but at least gives the idea of this kind of layering used to manage widgets and UI. Many more things could be explained about this topic like how you actually update a widget and how that affects the three trees, etc. I find useful to use OOP concepts to explain the structure, for example that the Widget is the class/object definition and the Element is the object instance which instead of being destroyed every time can be updated with new properties (and the Render element just draws it). So if you create a new instance of an object (a ui basic widget) Flutter will try to find an existing running instance in the tree to reuse instead of reinstantiating the object, that saves a lot in terms of performance, no need to destroy+construct but just update properties. Hope it can help.
Sorry guys, but this doesn't explain things quite well. Why are the widgets immutable? If they weren't, you wouldn't have to throw them away and could unite them with the element tree. And then you would end up with a 2-peer-architecture like Java Swing did: Swing had the logical components tree and the UI-Render-Objects tree. And an update to a logical component would only update it's UI-Render-Object. And you could change sub-trees (i.e. re-parenting) without creating any new objects. So I don't get the point why you made a third immutable layer.
thanks flutter team for the explanation. Flutter behind the scene mechanism always seems like a myth to me. But what if we change a parent widget, will the render object of it child widgets be removed as well? Or flutter is clever enough to know that the child are not changed so it simply remove the parent render object but keep the child render object and then build a new parent render object and link them back?
Few minutes of your presentation, and all those hours of tutos + books read make more sense ;) you guys really have a knack for those analogies, much like a mother bird chewing up some worms for her newborn helpless chicks :D Ive been struggling to get a firm answer, or find a soution for that matter - Is it possible to have a dynamic form, in so far as the number of fields as well as each fields type would only be known at runtime - for EG: could be a text / date picker / checkbox or multi-select.. In angular i would achieve this through its FOR & IF directives in the View itself, inserting all field types hidden by default, and conditionally unhiding & assigning to each of the models values/fields. If that makes sense. Is there someway similar could be achieved one way or another in Flutter ? Thanks in advance, & best regards
If every thing in flutter is widget then why are not they counting TextSpan object as Widget in sample code its constructor is called but still not counting?
TextSpan is just a container for the data. Its only job is to encapsulate strings and how they are annotated. Not literally all in flutter is a widget, some are data classes, and many others which is a feature of dart being object oriented language.
Very helpful video, thank you so much! Just one question, I find "RichText" widget extends "MultiChildRenderObjectWidget" in the source code (basis.dart), but is it correct it creates LeafRenderObjectElement the guy is talking around 9:27 ? Should it be MultiChildRenderObjectElement...?
When the element and render object are going to be destroyed(GC) when the widget tree structure isn't changed? For example, if you have PageA pushes PageB then pops PageB. I am guessing even you have popped PageB, but the render object and element won't be destroyed because they are still hanging to wait for another instance of PageB, so they can update the view correctly and efficiently? Is this right?
Why is the element or render object an expensive thing to generate, and skipping them makes it much faster? I feel like this wasn't answered, yet this is the fundamental assumption that needs to hold for this rendering to be efficient.
Because each rendering takes cpu and gpu load and when you render already existing objects, the real part to update takes significantly more time compared to skipping, and overall cpu gpu load increases and battery drains faster. Even though we are talking about maybe like miliseconds for small apps, why would you render 100 objects when you only changed one of them and that is the only thing to be updated ? There is no advantage of rendering everything again and again in lets say each keypress
@@admniyeokuyorsun...3044 but why do you need the widgets and elements tree for that. You can just calculate what's changed when a new widget is passed and update the render object directly
This is cool and i already invested a lot of time learning this cool lang.😇 i hope they will not kill the project after few years. As they are trying to cover more and more platforms which needs more and more human resources. And if the project wont generate any fruitful result/revenue. They gonna kill the project like the stadia. 😏
I think they had replaced the Chinese text with English text, I don't know how, but wow, thannks, I came here before when it was Chinese, and left miserably
sir when i have run flutter app in emulator,it runs correctly .when i see a emulator the app size is 97 mb,the app size is large .i have doubt if i use flutter for my project app size it would bigger , how to use flutter to develop big project
Depends on what you're doing, but you're most likely running the debug APK which is several times bigger than the release APK. Also, the relative differences in APK size would likely be smaller with larger apps, since Flutter's overhead size is fixed (~4Mb)
Not native GUI, OS cannot hook into GUI, accessibility. etc. There is no silver bullit. But hopefully they will adress accessibility at least!!! And they try to copy native GUI, to be close to the real thing.. But it's fake. Also OS hooks into the GUI is a difficult problem and needs "if solved" to be updates by every OS update.
@@HermanWillems google has decided to take the "update itself on every OS update" task, so we don't need to worry about that, and OS hooks can always be provided by native written packages or including native code when necessary
Shows how inefficient Flutter is with memory management when it comes to memory constrained devices... An overengineered mess, which will hopefully change in the future. This tongue-in-chick presentation does not justify the unnecessary 3 layers of UI rendering pipeline. dotNET went through the same mess of a UI in early days, and it was a memory hog like Flutter still is. Immutable UI design is the worst approach - I am surprised the brains at Google went that route. Every 5 years the wheel has to be reinvented it seems.
All of that feels unnecessarily convoluted. So far I am more confused about how I would create a custom layout for Widget's when I am in something like a RenderBox
After 5 months of flutter this is the only time i fully understand how flutter works, thanks for this great video
This is by far the best explanation about how Flutter render the UI. So, the secret of its performance is not only the Skia but also the application architecture and the amazing reuse of render objects. This is an outstanding work the Flutter team and community have made.
It's almost the same architecture as QT Quick. Only with different words. QML is a markup language that describes your UI, then you have a node of QQuickitems, and QSGNodes (which is the RenderObject here). And then with QT Quick it goes to OpenGL for fast rendering. It also only updates what changes, and doesn't change the widget. It's also super performant just like Flutter. And was here before. Have you ever been in a Tesla Model S or 3 or any Tesla? This whole UI = QT Quick. QT uses QML+Javascript on top. Where Flutter uses Dart (For both markup & scripting) Did you really think this is new technology? They just took that idea, and copied it... And for Skia, QT uses Qpainter which both have similar backends(for example OpenGL).
@@HermanWillems Nice info!!!!
I've been working on a passion project written in Flutter for quite a while. I've gained understanding of how it works under the hood by reading source code, but I've always had gaps and questions. In 26 minutes, Matt and Andrew taught me more about the framework than I've learned on my own in all that time. I want to thank Matt, Andrew, and the entire Flutter team for producing and publishing these instructional videos. The entire Flutter community is better for it.
Thank YOU the Flutter team for such a beautiful tool! Its a real beauty!
This is a much needed foundational explanation! Thank you for taking the time to create it!
In my beginner brain, it sounds like they are saying, well, just use the Widget tree and don't care if you duplicate stuff, because we will figure how that stuff is different in the Element tree for you and tell the RenderObject tree if anything needs to be done. So just concentrate on Widgets and "forget" about the other stuff.
@Flutter team: The video starts by explaining the solution, without explaining the actual problem which the architecture is supposed to solve, and what were the alternative architectures, and why this particular architecture was chosen by the flutter team. Would be enlightening, if you can make a video on that.
Nice! Somethings are making senses to me now...
Thank you Andrew and Matt for this helpfull presentation of the process flutter use to manage and render elements on the UI.
Flutter is very difficult in the beginning, but after learning, flutter is very amazing and easy
That's exactly what I'm feeling about it :)
yes , the concepts was very clear , the flutter architecture was awesome , it gives the apps work faster , great work flutter team
Finally this video is available.. YAY...
Explained very nice , thank you !
Excellent presentation
Recylcing as much as possible, flutter is actually saving the planet cause it doesn't pollute there does not produce waste lool
that's the word
This video explains how widget replacement is performed, but what happens if I insert a widget into the tree?
If I have tree A->B->C->D and insert widget E (say, a container) like so: A->E->B->C->D, how will Flutter react when it reaches widget E? Will it destroy the tree and widgets, elements, and render objects of "B, C, and D", or simply 'unlink' them, but keep them around in memory, and search through that pile of widgets on the side each time as it continues building the widget tree? Would that be facilitated by the widget keys, similar to the 'canUpdate' method? Then, does it clear that memory pile after finishing the whole tree update?
If anyone knows a good resource for further explanation, could they share?
so, widgets are like typed Props (except they define what "component" to use)
and Elements are like Components
and the rendering part is just different...
(when comparing it to React)
The explanation is superb.
Thanks for the clear explanation.
very good!
Thanks, Kroken! We appreciate you!
I don't understand that video :-( !
I know, how to use flutter, i know how games normally work, know many ways to manage the states in flutter and dart, but i dont't understand, how flutter really works. I.E. I can Not say, when flutter redraws my widgtes.
Please make another video for that ;-)
I agree the video is not complete but at least gives the idea of this kind of layering used to manage widgets and UI. Many more things could be explained about this topic like how you actually update a widget and how that affects the three trees, etc. I find useful to use OOP concepts to explain the structure, for example that the Widget is the class/object definition and the Element is the object instance which instead of being destroyed every time can be updated with new properties (and the Render element just draws it). So if you create a new instance of an object (a ui basic widget) Flutter will try to find an existing running instance in the tree to reuse instead of reinstantiating the object, that saves a lot in terms of performance, no need to destroy+construct but just update properties. Hope it can help.
Man timing! Turned off my wifi and at the same time this notif came! Gotta come back
Sorry guys, but this doesn't explain things quite well. Why are the widgets immutable? If they weren't, you wouldn't have to throw them away and could unite them with the element tree. And then you would end up with a 2-peer-architecture like Java Swing did: Swing had the logical components tree and the UI-Render-Objects tree. And an update to a logical component would only update it's UI-Render-Object. And you could change sub-trees (i.e. re-parenting) without creating any new objects. So I don't get the point why you made a third immutable layer.
Hopefully TH-cam will provide realtime video translation in future
Thanks a lot!It really helps!
thanks flutter team for the explanation. Flutter behind the scene mechanism always seems like a myth to me. But what if we change a parent widget, will the render object of it child widgets be removed as well? Or flutter is clever enough to know that the child are not changed so it simply remove the parent render object but keep the child render object and then build a new parent render object and link them back?
That is a good question, do you got an answer in the last year for that question? 😅
Such a wonderful video, thank you so much.
thankyou for this!!
The rendering tree logic essentially looks like in React
great video!!
Amazing, Thanks Flutter 💙
Very interesting! Great presentation!
Thank you!
This is great!!!
Few minutes of your presentation, and all those hours of tutos + books read make more sense ;) you guys really have a knack for those analogies, much like a mother bird chewing up some worms for her newborn helpless chicks :D Ive been struggling to get a firm answer, or find a soution for that matter - Is it possible to have a dynamic form, in so far as the number of fields as well as each fields type would only be known at runtime - for EG: could be a text / date picker / checkbox or multi-select.. In angular i would achieve this through its FOR & IF directives in the View itself, inserting all field types hidden by default, and conditionally unhiding & assigning to each of the models values/fields. If that makes sense. Is there someway similar could be achieved one way or another in Flutter ? Thanks in advance, & best regards
something has gone way wrong in web and mobile development in recent years, engineers must step in to fix this mess
Very good explanation, thanks!
nice again
If every thing in flutter is widget then why are not they counting TextSpan object as Widget in sample code its constructor is called but still not counting?
same question
TextSpan is just a container for the data. Its only job is to encapsulate strings and how they are annotated. Not literally all in flutter is a widget, some are data classes, and many others which is a feature of dart being object oriented language.
Great talk, but Chinese is a bit confusing 😕
Very true
So because of some Chinese titles you missed the whole point?
@@andrewfitzgibbon3236 much better now, thanks :)
@@andrewfitzgibbon3236 Could you tell us where can we get the slides? Thanks a lot!
Very helpful video, thank you so much! Just one question, I find "RichText" widget extends "MultiChildRenderObjectWidget" in the source code (basis.dart), but is it correct it creates LeafRenderObjectElement the guy is talking around 9:27 ? Should it be MultiChildRenderObjectElement...?
You are right, RichText showuld create MultiChildRenderObjectElement
Very helpful, thanks for sharing
nice explained
1:23 Isnt it 3 WIDGETS ? Center, RichText and TextSpan ?
"No Directionality Widget found" error if you run the code from the very first slide...
Supporting regional language is good thing. But we need translation. Can you please upload English version of slide and put it on description ❣️.
When the element and render object are going to be destroyed(GC) when the widget tree structure isn't changed?
For example, if you have PageA pushes PageB then pops PageB. I am guessing even you have popped PageB, but the render object and element won't be destroyed because they are still hanging to wait for another instance of PageB, so they can update the view correctly and efficiently? Is this right?
Isn’t it just dom diffing? Does React Native do the same thing?
Why is the element or render object an expensive thing to generate, and skipping them makes it much faster? I feel like this wasn't answered, yet this is the fundamental assumption that needs to hold for this rendering to be efficient.
Because each rendering takes cpu and gpu load and when you render already existing objects, the real part to update takes significantly more time compared to skipping, and overall cpu gpu load increases and battery drains faster. Even though we are talking about maybe like miliseconds for small apps, why would you render 100 objects when you only changed one of them and that is the only thing to be updated ? There is no advantage of rendering everything again and again in lets say each keypress
@@admniyeokuyorsun...3044 but why do you need the widgets and elements tree for that. You can just calculate what's changed when a new widget is passed and update the render object directly
I'd wish they covered Skia canvas and what happens on Android vs iOS
Thank you! It is a nice video.
awesome talk.....
thank you
Thank You!
Thank you so much
very informative
great talk
very nice
A big thanks to you, Heshan! We appreciate your continued support 😄
1st programming step, Hello China
Thanks💙
Why you are in china ?
Can anybody tell what's the lifecycle of a flutter application. Is it can update, createRenderObject and updateRenderObject??
This is great 🐦
why flutter web use only canvas for rendering? its too heavy compare to html and css style!
It still not has a widget like Recycler View from Android.
Does Flutter still behave this way?
2:51 before watchign this video i watched soem spiritual/philosophical content.
This is cool and i already invested a lot of time learning this cool lang.😇 i hope they will not kill the project after few years. As they are trying to cover more and more platforms which needs more and more human resources. And if the project wont generate any fruitful result/revenue. They gonna kill the project like the stadia. 😏
Awesome...
всё понятно и чётко.
that's great
why can't use widgettree+rendertree ? still not get the necessity of element tree .
The context is on the element tree, so the element tree tells others widget where they are.
How to add blender animation in flutter apps
Hello, Parshuram!
Great question!
We think you might find the following link useful:
goo.gle/3S4vPa8
Hope this helps 😎
Hopefully, Flutter team share slide.
That simple code will crash due to "No Directionality widget found"
You should add " textDirection: TextDirection.ltr," in the TextSpan
@@vanking8384 ah, I see. Thank you
I think they had replaced the Chinese text with English text, I don't know how, but wow, thannks, I came here before when it was Chinese, and left miserably
这个演讲是在上海？中文讲这个的太少了，视频更是没有。只有来这里看视频才了解到了flutter渲染的原理（或者说是3颗树的设计目的？），26分钟的视频我看了快一个小时，看一句就暂停一下看英文字幕，谁叫英文学的是哑巴英语😂 （机器翻译还是有问题，有些地方不够准确）
Isn't that funny: China is blocking Google and Google makes special event for China. So sweet
Топовая связка, постоянно прокачиваю денежку.
I in love with you #Flutter
Next presentation in wingdings fonts please
sir when i have run flutter app in emulator,it runs correctly .when i see a emulator the app size is 97 mb,the app size is large .i have doubt if i use flutter for my project app size it would bigger ,
how to use flutter to develop big project
Depends on what you're doing, but you're most likely running the debug APK which is several times bigger than the release APK.
Also, the relative differences in APK size would likely be smaller with larger apps, since Flutter's overhead size is fixed (~4Mb)
Proabably running in debug mode
i am waiting for nihow animation
Quick question: Any downsides of this?
Not native GUI, OS cannot hook into GUI, accessibility. etc. There is no silver bullit. But hopefully they will adress accessibility at least!!! And they try to copy native GUI, to be close to the real thing.. But it's fake. Also OS hooks into the GUI is a difficult problem and needs "if solved" to be updates by every OS update.
@@HermanWillems google has decided to take the "update itself on every OS update" task, so we don't need to worry about that, and OS hooks can always be provided by native written packages or including native code when necessary
Can't you edit the video and translate the Chinese text? At least add subtitles
你好
Shows how inefficient Flutter is with memory management when it comes to memory constrained devices... An overengineered mess, which will hopefully change in the future. This tongue-in-chick presentation does not justify the unnecessary 3 layers of UI rendering pipeline. dotNET went through the same mess of a UI in early days, and it was a memory hog like Flutter still is. Immutable UI design is the worst approach - I am surprised the brains at Google went that route. Every 5 years the wheel has to be reinvented it seems.
你好
It would be a great talk if I can read Chinese but now it is just your speech and thus harder to follow
All of that feels unnecessarily convoluted. So far I am more confused about how I would create a custom layout for Widget's when I am in something like a RenderBox
ni hao~
React does the same thing using virtual dom and diffing.
video with english title that contains chinese texts. very smart