-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[multi window] Constellation should not assume there's one and only one compositor #13993
Comments
Something that I don't run into often, but that is very annoying when it does happen, is plugging in an external monitor with a different DPI and Firefox forcing one scaling factor for all windows. Would love to see this work properly in Servo! |
Would it be somewhat correct to say that what we need is some combination of The way I see it in your example in #13994 (comment), So I guess one way to look at it, in the context of your example, is that constellation would need something like a |
warning: "Tabs" and "BrowserManager" are just temporary names I used in that prototype. "Tabs" are not a concept that we have in Servo. And I don't think we want that to ever happen. We talk about top level frames. "BrowserManager" is a fancy name for the constellation from the point of view of the embedder. My example assume only one window (one compositor). We want only one constellation.
Yes.
BrowserManager is the constellation. Even though in this example it's also a link to the compositor.
The constellation will hold references to multiple compositors.
Tabs is really just a temporary struct I use in the embedder. Servo doesn't know about Tab and Tabs. |
@paulrouget Ok thanks a lot for the clarification. Can we add the "assigned" level, and say I am taking on this one? I will check with @glennw re how his work on allowing multiple WR's is/can affect this issue and how I can best start to work on it... |
Done. |
Multiple WR instances works correctly now. It might be a bit tedious to have a hashmap instead of a direct link to the compositor as we will have to send events to the relevant compositor. Many events, like I'm also wondering how the API to create and destroy a compositor will look like. Also, the Maybe events like |
Ok, I can leave this one to you @paulrouget, as I was planning on first taking a first pass at the http cache. Happy to pick up some subset of this issue later on, and off course continue working on other issues with implementing |
@paulrouget Are you still working on this? |
Not at the moment, still on my todo list though. |
Just started to work on this. |
Need #19679 |
Priorities changed. I haven't got a chance to finish this. |
I think we should implement this in this order:
|
The constellation assume there's one and only one compositor. When Servo will support multiple windows, this won't be true anymore.
We also want to be able to start Servo with no compositor at all. A compositor requires a gl buffer, so Servo can be loaded only once a gl buffer is available. This makes the work of the embedder a bit difficult.
Things like pixel density, window size, screen size, … can be different depending on the window.
This is a required step for multi window support.
I'd imagine that we would need a hashmap of top level frames <-> compositors.
The text was updated successfully, but these errors were encountered: