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
This is a tracking bug for tracking the migration steps for implementing the multi-window API described in this design doc.
The steps for migration are:
Convert engine internals to an API that understands multiple windows/screens, but only supports one one window.
Convert the dart:ui Dart classes to use the internal engine API, but still only supports one window.
Add platform detection of screens on the platform, reporting the proper size for the screens that the window appears on (still only managing one screen and one window)
Add platform support for multiple screens and one window
Add support for creating multiple windows, allowing creation and disposal, but not reconfiguration.
Hi, I'm so appreciated to see the design doc to implement the multi-window mechanism which support window/screen/view concept, and one FlutterWindow can contain child views called FlutterWindowView.
In our business scenarios, We strongly need the feature that one FlutterWindow contains multi FlutterWindowViews, so that we can use these FlutterWindowViews integrate with the native platform views, but i'm not very sure if we can implement these with the design doc talked about.
I check out your Engine/flutter repository with the multi-window-framework/engine branch, I see it only implement the API and SingletonFlutterWindow rendering which originally is the window class. And i also see you comments with 'resource constrained at the moment'.
So my questions:
Whether multi FlutterWindowViews in one FlutterWindow accurately map with the multi surface views in Android or not?
What are the next plans about this feature? This seems has been last for a bit long.
Whether we can talk about the design doc and cooperate to complete the full implementation ASAP or not? 😄
@lybeen and I are trying to support to embed multiple flutterviews in a single native page in ios and android.
Do you have a schedule to support this feature in mobile side? @gspencergoog
@lybeen@kangwang1988 Yes, that branch only contains the first steps to getting to a multi-window world, and I'm currently splitting that up into pieces to be able to be more easily reviewed (e.g. see this "work in progress" PR)
I think it does make sense to have some kind of Flutter widget that can host a platform view and be placed inside of a FlutterWindow, and also that FlutterWindowViews could be hosted by a platform view so that they can be embedded in platform windows, but I haven't laid out the details for doing that yet. The FlutterWindow and FlutterWindowView are intended to only host Flutter content (which is why they have Flutter in the name). Initially, our focus is just to make it possible to have multiple windows on desktop platforms, and to focus later on making those windows host multiple views, and then extending multiple views to mobile platforms.
The current implementation plan for multi-window support is to follow the steps listed in the issue description above. I think embedding multiple views into a single window comes after those steps, but at a certain point it could be worked on in parallel.
At the moment, there is no concrete schedule for completing the work, but multiple window support is a priority for us.
As always, we would welcome feedback on the design doc, as well as any help you would like to contribute to the implementation or design.
That's wonderful. @lybeen and I will keep up with this work and check if we can do something to speed up this work.
It's been a desire for business units from the very beginning especially in a add2app scenario. The assumption or requirement that we should use flutter in one page is too strict. Now we want to make a step forward to support more fine support to add flutter into already existing app.
@gspencergoog I have looked through the design doc and the listed open questions , I think there is another problem we would refactor:
In current flutter design , there exists one global LayerTreePipeline in animator , this is A thread-safe queue of resources for a single consumer and a single producer. It means throughout one frame rendering, it must be committed only once(one Produce, one Consume should be paired).
So in multi-window if we should commit vector scene with the function like void render(List<Scene> scene) native 'PlatformConfiguration_render'; or How do we design the window render function with scene in on frame rendering process ?
@gspencergoog is there a design document for multi-window that is more updated than the one found here, or is this still the go-to? I'm asking because the PR's linked in that doc (and this issue) are both closed, which seems to indicate the doc is out of date. I'd like to get a better picture of the team's plans for multi-window, and there's been no discussion on this issue for two years now.
@GroovinChip Unfortunately, no, at the moment there isn't a more updated doc. That one is still relevant, but definitely out of date. @goderbauer does have some prototypes going, and we're making progress, but haven't updated the design doc. You're right that although we've had a lot of informal discussions, it would be good to update the formal documents.
I am currently fine tuning the prototype for multi views (which is one of the steps we need to take to eventually get to multi window). Writing the findings from the prototype up into a formal document is next.
Thanks for the updates @gspencergoog and @goderbauer! I'm looking forward to reading the findings from the prototype. Multi-window is really important for those of us working in the desktop space, and I'm excited to see it make it's (eventual) official debut.
To clean up some of the multi window issues I am going to close this umbrella issue. We track most of the work towards multi window in Multi Window (view).
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
lybeen commentedon Jul 7, 2020
Hi, I'm so appreciated to see the design doc to implement the multi-window mechanism which support window/screen/view concept, and one FlutterWindow can contain child views called FlutterWindowView.
In our business scenarios, We strongly need the feature that one FlutterWindow contains multi FlutterWindowViews, so that we can use these FlutterWindowViews integrate with the native platform views, but i'm not very sure if we can implement these with the design doc talked about.
I check out your Engine/flutter repository with the multi-window-framework/engine branch, I see it only implement the API and SingletonFlutterWindow rendering which originally is the window class. And i also see you comments with 'resource constrained at the moment'.
So my questions:
kangwang1988 commentedon Jul 7, 2020
@lybeen and I are trying to support to embed multiple flutterviews in a single native page in ios and android.
Do you have a schedule to support this feature in mobile side? @gspencergoog
gspencergoog commentedon Jul 7, 2020
@lybeen @kangwang1988 Yes, that branch only contains the first steps to getting to a multi-window world, and I'm currently splitting that up into pieces to be able to be more easily reviewed (e.g. see this "work in progress" PR)
I think it does make sense to have some kind of Flutter widget that can host a platform view and be placed inside of a
FlutterWindow, and also thatFlutterWindowViews could be hosted by a platform view so that they can be embedded in platform windows, but I haven't laid out the details for doing that yet. TheFlutterWindowandFlutterWindowVieware intended to only host Flutter content (which is why they have Flutter in the name). Initially, our focus is just to make it possible to have multiple windows on desktop platforms, and to focus later on making those windows host multiple views, and then extending multiple views to mobile platforms.The current implementation plan for multi-window support is to follow the steps listed in the issue description above. I think embedding multiple views into a single window comes after those steps, but at a certain point it could be worked on in parallel.
At the moment, there is no concrete schedule for completing the work, but multiple window support is a priority for us.
As always, we would welcome feedback on the design doc, as well as any help you would like to contribute to the implementation or design.
gspencergoog commentedon Jul 7, 2020
/cc @zoeyfan @csells
kangwang1988 commentedon Jul 7, 2020
That's wonderful.
@lybeen and I will keep up with this work and check if we can do something to speed up this work.
It's been a desire for business units from the very beginning especially in a add2app scenario. The assumption or requirement that we should use flutter in one page is too strict. Now we want to make a step forward to support more fine support to add flutter into already existing app.
lybeen commentedon Jul 8, 2020
@gspencergoog Thanks a lot, I will look into more detail about the design doc.
lybeen commentedon Jul 11, 2020
@gspencergoog I have looked through the design doc and the listed open questions , I think there is another problem we would refactor:
In current flutter design , there exists one global LayerTreePipeline in animator , this is
A thread-safe queue of resources for a single consumer and a single producer.It means throughout one frame rendering, it must be committed only once(one Produce, one Consume should be paired).So in multi-window if we should commit vector scene with the function like
void render(List<Scene> scene) native 'PlatformConfiguration_render';or How do we design the window render function with scene in on frame rendering process ?[-]Migration to multi-window API[/-][+]☂️ Migration to multi-window API[/+]GroovinChip commentedon Aug 9, 2022
@gspencergoog is there a design document for multi-window that is more updated than the one found here, or is this still the go-to? I'm asking because the PR's linked in that doc (and this issue) are both closed, which seems to indicate the doc is out of date. I'd like to get a better picture of the team's plans for multi-window, and there's been no discussion on this issue for two years now.
gspencergoog commentedon Aug 9, 2022
@GroovinChip Unfortunately, no, at the moment there isn't a more updated doc. That one is still relevant, but definitely out of date. @goderbauer does have some prototypes going, and we're making progress, but haven't updated the design doc. You're right that although we've had a lot of informal discussions, it would be good to update the formal documents.
goderbauer commentedon Aug 9, 2022
I am currently fine tuning the prototype for multi views (which is one of the steps we need to take to eventually get to multi window). Writing the findings from the prototype up into a formal document is next.
GroovinChip commentedon Aug 9, 2022
Thanks for the updates @gspencergoog and @goderbauer! I'm looking forward to reading the findings from the prototype. Multi-window is really important for those of us working in the desktop space, and I'm excited to see it make it's (eventual) official debut.
goderbauer commentedon Mar 27, 2023
To clean up some of the multi window issues I am going to close this umbrella issue. We track most of the work towards multi window in Multi Window (view).
github-actions commentedon Apr 11, 2023
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.