Comments (4)
After investigating a bit, it does seems like if no properties of any RenderObject change, then there's no paint step requested. And even if the widget itself change, it doesn't necessarily end with a layout step.
So in the end, you are right, it does seem like if no RenderObject changes at all, "nothing" happens. It will still rebuild the whole tree, but not necessarily relayout and repaint everything.
Anyway, I'd still suggest investigating the performance impact of rebuilding a tree of 600+ widgets.
In the current state of the README it's hard not to fear performances problems on big applications.
from dartea.
Hi @rrousselGit , first of all thank you for opening this interesting issue, because the statement in readme isn't accurate.
Yes, you're right, that's calling setSet
from a parent-widget doesn't necessary force to rebuild its child. But I was saying about Dartea application, not about Flutter in general. Typical Dartea application widgets tree looks like this:
MaterialApp (or Cupertino, or WidgetsApp) | DarteaWidget | Some container / | \ Widget1 Widget2 Widget3
In this hierarchy only DarteaWidget
is stateful and its setState()
is called when model has changed. It triggers rebuild for DarteaWidget
and inside it view
function is called, which is usually returns new instance of some widget, Dartea doesn't do any caching or memoization. In current case every model change triggers rebuild for the whole widgets tree (which is defined by composition of view
functions). And this is fine for Elm application, and I guess that is not so bad for Flutter application.
By incremental changes
I meant that rebuilding widgets tree doesn't force to recreate all render objects, instead it just do incremental updates properties of render objects. I just wanted to say, that creating of Widgets is cheap in Flutter.
Please correct me if I'm wrong, or if it's still unclear to you.
I want to update this section in readme + maybe give some advice for performance improvements in Dartea applications.
from dartea.
I see, I misunderstood that part then.
And this is fine for Elm application, and I guess that is not so bad for Flutter application.
By incremental changes I meant that rebuilding widgets tree doesn't force to recreate all render objects, instead it just do incremental updates properties of render objects. I just wanted to say, that creating of Widgets is cheap in Flutter.
One difference with Elm is that the browser only redraw what changed. In flutter this is not the case. If a single RenderObject update, the whole tree may repaint with it unless you add repaintboundaries.
But with such method, you can't even use repaintboundaries as the widget tree is always entirely recreated.
This may be fine for relatively small layouts. But I don't quite see it efficient for huge tree with thousands of widgets in it.
Exposing the Model using an InheritedModelWidget would be much more efficient.
from dartea.
I see what you mean.
I believe that there should be performance degradation on a huge widgets tree, but still I want to try profiling and investigation first. I've tried debugRepaintRainbowEnabled
property to visualize repainted boxes, and it looks like not whole tree is repainted, see attached gif.
Also I can try to add possibility to memoize results of view
function somehow (something similar to current Redux approach). Even though currently we can do it manually, but I think it should be out of the box.
from dartea.
Related Issues (17)
- type 'NoSuchMethodError' is not a subtype of type 'Exception' HOT 3
- DarteaMessageBus not found HOT 1
- TextFields are getting rebuild even when I use GlobalKeys. HOT 9
- How to get Scaffold context inside of _view? HOT 1
- How can i effective forward message to another model? HOT 1
- How to force to update widgets upon certain circumstances? HOT 4
- What if one need pass some parameters to _init..?
- AppLifeCycleState, no constant named suspending HOT 2
- How to do routing? HOT 2
- migrate to AndroidX fails HOT 3
- Convert to `Sound null safety`
- Dartea for a Webapp HOT 2
- Awesome HOT 4
- copyWith HOT 2
- Could this package be used with AnguarDart? HOT 3
- May I use a single big model object instead of many models? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dartea.