Currently, the window actor freeze/thaw implementation sets the frozen
state of the surface actor using `meta_surface_actor_set_frozen()`.
If we want to expand that behavior to also freeze/thaw commits for X11
windows running on Xwayland, we need to have a specific vfunc to abstract
that in the window actor specific implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Make sure we freeze commits before resizing the window as this will
clear the frame to black.
Set the "thaw on paint" flag so that the post paint for window actor X11
can then thaw the freeze initiated prior to the resize and keep the
freeze/thaw balanced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.
The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.
The same context is passed around for paint nodes, contents and effects
as well.
In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Move out updating of various shapes (input, opaque, shape) indirectly
from X11 to the corresponding X11 sub types of MetaWindowActor and
MetaSurfaceActor.
Also move fullscreen window unredirection code with it. We want to
effectively do something similar for MetaCompositorServer, but it will
work differently enough not to share too much logic.
While it would have been nice to move things piece by piece, things were
too intertwined to make it feasible.
This has the side effect fixing accidentally and arbitrarily adding
server side shadow to Wayland surfaces.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/727https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
Flatten the subsurface actor tree, making all surface actors children
of the window actor.
Save the subsurface state in a GNode tree in MetaWaylandSurface, where
each surface holds two nodes, one branch, which can be the tree root
or be attached to a parent surfaces branch, and a leaf, which is
used to save the position relative to child branch nodes.
Each time a surface is added or reordered in the tree, unparent all
surface actors from the window actor, traverse all leaves of the
tree and readd the corresponding surface actors back to the window
actor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/664
The way code was structured made it easy to misunderstand things as the
surface actor of a window actor could change over time. So is not the
case, however, the intention of the corresponding "update" function was
so that a surface actor could be assigned to a window actor as soon as
the X11 window was associated with its corresponding wl_surface, if the
window in question came from Xwayland.
Restructure the code and internal API a bit to make it clear that a
window actor only once gets a surface actor assigned to it, and that it
after that point never changes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/659
This vfunc was added as a was to work around the convoluted
initialization process. Now that we figured it out and moved
the MetaWindowActor-specific initialization to constructed(),
we can override that.
Remove post_init() and use GObject.constructed() entirely.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
MetaWindowActor handles sending _NET_WM_FRAME_* X atoms to
clients - even pure Wayland clients.
Now that we have Wayland- and X11-specific implementations of
MetaWindowActor, we can delegate this to MetaWindowActorX11,
and allow pure Wayland apps to not even connect to
MetaSurfaceActor:repaint-scheduled.
Do that by moving all the X11-specific code to the X11-specific
MetaWindowActorX11 class. Add vfuncs to MetaWindowActorClass
that are necessary for the move, namely:
* pre_paint() and post_paint()
* post_init()
* frame_complete()
* set_surface_actor()
* queue_frame_drawn()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
Those are stub specialized classes for MetaWindowActor. This will
help ensuring that we do not execute X11-specific code paths on
pure Wayland clients.
The relationship between the window actor and the surface is the
following:
* Wayland: MetaWindowActorWayland + MetaSurfaceActorWayland
* X11: MetaWindowActorX11 + MetaSurfaceActorX11
* Xwayland: MetaWindowActorX11 + MetaSurfaceActorWayland
It is not possible to have MetaWindowActorWayland backed by a
MetaSurfaceActorX11 surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/368
