GNOME Bugzilla – Bug 678989
Allow multiple MetaWindowActors per window
Last modified: 2014-01-17 14:27:58 UTC
This is a plan that I have to make displaying a window much easier, so we don't have to play reparenting and stex hacks. The idea is that the shell would just do: let w = new Meta.WindowActor({ meta_window: my_meta_window }); stage.add_actor(w); And it can move it around, and mutter won't touch it at all, or sync its position. The eventual goal is to just have the mutter compositor be managing its own window actor like anybody else, so we remove the "core actor" or "compositor private" entirely, and all of the special hooks that go along with it.
Created attachment 217420 [details] [review] window-actor: Remove (private) xwindow property This should make it easier to construct a MetaWindowActor from bindings. There's some potential annoying boilerplate code that I'm planning on cleaning up into a separate meta_window_get_toplevel_xwindow utility method.
Created attachment 217421 [details] [review] window-actor: Remove meta-screen property This can be inferred from the window. Don't allow anybody to set it.
Created attachment 217422 [details] [review] window-actor: Make the meta-window property construct-only We don't deal with setting this property at all, and it's unlikely to come up in future settings, so just don't allow setting it at all.
Created attachment 217423 [details] [review] Allow potentially supporting multiple MetaWindowActors per window A lot of the code in mutter assumed a one to one relationship between a MetaWindow and a MetaWindowActor, and that it owns its MetaWindowActor. For the most part, we've gotten around this in GNOME Shell by creating a ClutterClone of the MetaWindowActor. In some spots, we reparent the actor owned by Mutter, and use it for our own purpose, which just plain isn't nice. Since the Clutter mafia has plans to drive a bullet through ClutterClone, and since MetaWindowActor is already a very thin wrapper around MetaShapedTexture, we should be able to create multiple MetaWindowActors for a MetaShapedTexture. This commit replaces the "compositor_private" property on MetaWindow with a direct reference to a MetaWindowActor (which may go away at some point, see below), and a list of window actors. The direct reference is a replacement for the "compositor_private" property that has been there previously. It doesn't make sense to run mutter without compositing, so there's no real reason to keep the veil of a compositor/core split. The eventual plan I have in mind is to remove the direct reference to MetaWindowActor, and have the compositor/plugin just create a new window actor like anybody else.
Created attachment 217424 [details] [review] window-actor: Don't do any special initialization in _new
Created attachment 218149 [details] [review] Allow potentially supporting multiple MetaWindowActors per window A lot of the code in mutter assumed a one to one relationship between a MetaWindow and a MetaWindowActor, and that it owns its MetaWindowActor. For the most part, we've gotten around this in GNOME Shell by creating a ClutterClone of the MetaWindowActor. In some spots, we reparent the actor owned by Mutter, and use it for our own purpose, which just plain isn't nice. Since the Clutter mafia has plans to drive a bullet through ClutterClone, and since MetaWindowActor is already a very thin wrapper around MetaShapedTexture, we should be able to create multiple MetaWindowActors for a MetaShapedTexture. This commit replaces the "compositor_private" property on MetaWindow with a direct reference to a MetaWindowActor (which may go away at some point, see below), and a list of window actors. The direct reference is a replacement for the "compositor_private" property that has been there previously. It doesn't make sense to run mutter without compositing, so there's no real reason to keep the veil of a compositor/core split. The eventual plan I have in mind is to remove the direct reference to MetaWindowActor, and have the compositor/plugin just create a new window actor like anybody else. ---- Disconnect signal handlers from the window when the actor is destroyed.
Created attachment 218150 [details] [review] window-group: Turn into a public class, make easier to use
"Since the Clutter mafia [...]" ... do we really need such stuff in commit messages?
Created attachment 218154 [details] [review] Allow potentially supporting multiple MetaWindowActors per window A lot of the code in mutter assumed a one to one relationship between a MetaWindow and a MetaWindowActor, and that it owns its MetaWindowActor. For the most part, we've gotten around this in GNOME Shell by creating a ClutterClone of the MetaWindowActor. In some spots, we reparent the actor owned by Mutter, and use it for our own purpose, which just plain isn't nice. Since the Clutter maintainers have plans to kill off ClutterClone, and since MetaWindowActor is already a very thin wrapper around MetaShapedTexture, we should be able to create multiple MetaWindowActors for a MetaShapedTexture. This commit replaces the "compositor_private" property on MetaWindow with a direct reference to a MetaWindowActor (which may go away at some point, see below), and a list of window actors. The direct reference is a replacement for the "compositor_private" property that has been there previously. It doesn't make sense to run mutter without compositing, so there's no real reason to keep the veil of a compositor/core split. The eventual plan I have in mind is to remove the direct reference to MetaWindowActor, and have the compositor/plugin just create a new window actor like anybody else. uh, yeah... It must have been really late when I wrote that commit message.
Review of attachment 218154 [details] [review]: As I already noted on IRC you cannot create multiple TFP textures out of the same drawable on NVIDIA so this would result into cogl falling back to XGetImage in that case an potentially slow things down.
(In reply to comment #10) > Review of attachment 218154 [details] [review]: > > As I already noted on IRC you cannot create multiple TFP textures out of the > same drawable on NVIDIA so this would result into cogl falling back to > XGetImage in that case an potentially slow things down. Right, Owen also said that he didn't like the shaping work being done multiple times. I don't know about the correct approach for this, especially wrt. Clutter 2.0 portability-ness. We're going to chat about it at GUADEC.
Most of these patches already landed for Wayland support. I still want to do the "multiple MetaWindowActor"s cleanup, but the code has changed so much that I'm not sure it's possible, and Owen's frame sync stuff makes it more complicated.