You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Offer options that balances embeddable Flutter load time with resource consumption #32946
We should identify the right balance point between loading the embedding / vm / isolate / framework / userland element tree / resources in the tree based on each part’s load time vs its memory use.
This involves #32945 to audit cold init time and also auditing memory consumption.
Our recommended embedding strategy + default behaviors from APIs should be reasonably balanced between fast loading and memory usage.
Document alterations users can make given those APIs such as prewarming/keeping the vm only, prewarming/keeping the isolate. Flutter side APIs to flush parts of the tree when window is not visible.
This sounds like it might imply new APIs for such control? If so, those APIs probably sit at the basest level of the system and we should resolve these concerns ASAP. I imagine that this could impact bootstrapping behavior for the native system, as well as core APIs for all embeddings...
I agree, this is the first task I'm looking at. I'm still not sure yet whether this involves just fixing bugs or our existing APIs can't offer the right degree of control for our users.
The framework side of it will mostly be just #32871 (in making sure that there's a documented way of unloading things once the window is no longer attached).
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.
Activity
matthew-carroll commentedon Jun 6, 2019
This sounds like it might imply new APIs for such control? If so, those APIs probably sit at the basest level of the system and we should resolve these concerns ASAP. I imagine that this could impact bootstrapping behavior for the native system, as well as core APIs for all embeddings...
xster commentedon Jun 6, 2019
I agree, this is the first task I'm looking at. I'm still not sure yet whether this involves just fixing bugs or our existing APIs can't offer the right degree of control for our users.
xster commentedon Jun 7, 2019
In scope is to fix
Whether by API changes or fixing bugs
xster commentedon Jun 15, 2019
Part of the issue above is likely #26007
goderbauer commentedon Jun 17, 2019
I am not sure I understand what this issue is asking for. Specifically, what's needed from the framework to fix this (since it has the framework tag)?
xster commentedon Jun 18, 2019
The framework side of it will mostly be just #32871 (in making sure that there's a documented way of unloading things once the window is no longer attached).
github-actions commentedon Aug 26, 2021
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 -vand a minimal reproduction of the issue.