As explained in the last commits, we'll let gnome-shell take care of
this since freezing and thawing needs to be decoupled from the effect
starting and ending.
So stop freezing the MetaWindowActor when starting the effect and
thawing the actor when ending the effect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
As explained in the last commit, gnome-shell needs to be able to thaw
window actor updates during its size-change effect is active.
So make meta_window_actor_freeze() and meta_window_actor_thaw() public
API, which will allow the shell to freeze and thaw actor updates itself.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
The size-change animation in gnome-shell needs to sync the window actors
geometry during the animation, it currently does this by notifying the
compositor that the animation was finished before it actually is.
This causes a few bugs in Mutter though, since it will now emit the
"effects-completed" signal on the window actor even though they aren't
completed.
To fix that, we need to decouple freezing and thawing of actor updates
from window effects and allow gnome-shell to thaw actor updates before
it notifies Mutter that the effect is completed.
The first step for this is allowing to sync the actor geometry while an
effect is active, this should be redundant since effects which actually
need to inhibit those updates will freeze the actor anyway. Also a
geometry change happening while another effect is active will kill the
old effect anyway because MetaPluginManager kills all the active window
effects before starting a new one; so the new size-change effect for any
geometry change is going to kill the current effect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
A paint flag affects a paint operation in ways defined by the flags.
Currently no flags are defined, so no semantical changes are defined
yet. Eventually a flag aiming to avoid painting of cursors is going to
be added, so that screen cast streams can decide whether to include a
cursor or not.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
This fixes an issue where a non-maximized screen casted window would be
stretched to fill the whole screen cast stream, instead of just the crop
that corresponds to the current window size.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1174
Normally we bail out in `sync_actor_geometry()`. The comment there
states:
```
Normally we want freezing a window to also freeze its position; this allows
windows to atomically move and resize together, either under app control,
or because the user is resizing from the left/top. But on initial placement
we need to assign a position, since immediately after the window
is shown, the map effect will go into effect and prevent further geometry
updates.
```
The signal for the initial sync originates in `MetaWindow` though and predates
`xdg_toplevel_set_maximized`, which again calls `meta_window_force_placement`,
triggering the signal too early. As a result, Wayland clients that start up
maximized have a wrong map animation, starting in the top-left corner.
In order to fix this without changing big parts of the geometry logic and risking
regressions, force the initial sync again before mapping.
Solution suggested by Jonas Ådahl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1164
This allows us to screencast any window continuously, even
without it being visible. Because it's still being painted,
clients continue to receive frame callbacks, and people
are happy again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
cogl_framebuffer_push_rectangle_clip() acts on the current modelview
matrix. That means the result of clipping then translating will be
different of the result of translating then clipping.
What we want for window screencasting is the former, not the latter.
Move the translation code (and associated) to after clipping.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/1097https://gitlab.gnome.org/GNOME/mutter/merge_requests/1129
For X11 clients running on Xwayland, the opaque, input and shape regions
are processed from different properties and may occur at a different
time, before the actual buffer is eventually committed by Xwayland.
Add a new API `update_regions` to window actor to trigger the update of
those regions when needed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
Much like monitor streaming, implement window streaming by
making the window actor draw itself with a paint context
that used the passed framebuffer.
Now that all MetaScreenCastStreamSrc subclasses implement
blit_to_framebuffer, remove the conditional check from
meta_screen_cast_stream_src_blit_to_framebuffer().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1086
It is only useful for clients that do not set an opaque region but
still can be detected as being opaque. This is helpful for X11 clients
as opaque regions only got introduced around 2012 and only as part of EWMH
and are thus not used in many cases.
On Wayland however opaque regions have been part of the core protocol from the
beginnig and we can assume they are used more commonly.
As the current implementation in `MetaWindowActor` does not handle Wayland
subsurfaces well, instead of adding more complexity just move it to
`MetaWindowActorX11`.
While on it, take the shape region into account that is set when clients
use the X Nonrectangular Window Shape Extension Protocol, so we have exact
culling with those clients.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1058
The frame bounds as returned by `meta_window_actor_get_frame_bounds()`
would be used as cropping values when streaming a window content.
But, as its name implies, it returns the actual frame bounds, whereas we
may want to include the whole buffer, to include client side shadows for
example.
Rename the `get_frame_bounds()` API to `get_buffer_bounds()` (which was
previously partly removed with commit 11bd84789) and return the actual
buffer bounds to use as the cropping area when streaming a window.
Fixes: 931934511 - "Implement MetaScreenCastWindow interface"
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1022
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1018
The clip bounds passed in `meta_window_actor_capture_into()` represent
the actual allocated buffer size where the window actor image will be
eventually copied.
As such, it is completely agnostic to the scaling factors that might
affect the different surface actors which compose the window actor.
So instead of trying to compute the scale factor by which the given
clipping bounds need to be adjusted, simply clip the resulting image
based on the given bounds to make sure we never overflow the destination
buffer.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1022
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
From `meta_cullable_cull_out`:
```
Actors that may have fully opaque parts should also subtract out a region
that is fully opaque from @unobscured_region and @clip_region.
```
As we do no check for the intersection of these two elsewhere in the code,
let's substract from the clip region, too.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/985
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
The commit f2f4af0d50 missed one situation
where mutter does things differently, i.e. changes what surface actor is
associated with a given window actor: reparenting a Xwayland window when
changing whether it is decorated.
To summarize, there are three types of window actors:
X11 window actors - directly tied to the backing X11 window. The
corresponding surface actor is directly owned by the window actor and
will never change.
Wayland window actors - gets its surface actor from MetaWaylandSurface
at construction. A single MetaWaylandSurface may create and destroy
multiple window actors over time, but a single window actor will never
change surface actor.
Xwayland window actors - a mix between the above two types; the window
corresponds to the X11 window, and so does the window actor, but the
surface itself comes from the MetaWaylandSurface.
Normally when a X11 window is unmapped, the corresponding MetaWindow is
unmanaged. With Xwayland, this happens indirectly via the destruction of
the wl_surface. The exception to this is windows that are reparented
during changing their decoration state - in this case on plain X11, the
MetaWindow stays alive. With Xwayland however, there is a race
condition; since the MetaWindow is tied to the wl_surface, if we receive
the new surface ID atom before the destruction of the old wl_surface,
we'll try to associate the existing MetaWindow and MetaWindowActor with
the new wl_surface, hitting the assert. If the surface destruction
arrives first, the MetaWindow and MetaWindowActor will be disposed, and
the we wouldn't hit the assert.
To handle this race gracefully, reinstate handling of replacing the
surface actor of an existing window actor, to handle this race, as it
was handled before.
Eventually, it should be reconsidered whether the MetaWindow lifetime is
tied to the wl_surface or if it should be changed to be consistent with
plain X11, as this re-exposes another bug where the X11 client and
mutter will enter a feedback loop where the window is repeatedly
remapped. See https://gitlab.freedesktop.org/xorg/xserver/issues/740.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/709https://gitlab.gnome.org/GNOME/mutter/merge_requests/773
This currently uses a hack where it pushes a CoglFramebuffer backed by a
texture to the framebuffer stack, then calls clutter_actor_paint() on
the window actor causing it to render into the framebuffer. This has the
effect that all subsurfaces of a window will be drawn as part of the
window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
Make it possible to listen for damage on a window actor. For X11, the
signal is emitted when damage is reported; for Wayland, it is emitted
when any of the surfaces associated with the window is damaged.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/752
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
Geometry scale is applied to each surface individually, using
Clutter scales, and not only this breaks subsurfaces, it also
pollutes the toolkit and makes the actor tree slightly too
fragile. If GNOME Shell mistakenly tries to set the actor scale
of any of these surfaces, for example, various artifacts might
happen.
Move geometry scale handling to MetaWindowActor. It is applied
as a child transform operation, so that the Clutter-managed
scale properties are left untouched.
In the future where the entirety of the window is managed by a
ClutterContent itself, the geometry scale will be applied
directly into the transform matrix of MetaWindowActor. However,
doing that now would break the various ClutterClones used by
GNOME Shell, so the child transform is an acceptable compromise
during this transition.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
MetaWindowActor is the compositor-side representative of a
MetaWindow. Specifically it represents the geometry of the
window under Clutter scene graph. MetaWindowActors are backed
by MetaSurfaceActors, that represent the windowing system's
surfaces themselves. Naturally, these surfaces have textures
with the pixel content of the clients associated with them.
These textures are represented by MetaShapedTexture.
MetaShapedTextures are currently implemented as ClutterActor
subclasses that override the paint function to paint the
textures it holds.
Conceptually, however, Clutter has an abstraction layer for
contents of actors: ClutterContent. Which MetaShapedTexture
fits nicely, in fact.
Make MetaShapedTexture a ClutterContent implementation. This
forces a few changes in the stack:
* MetaShapedTexture now handles buffer scale.
* We now paint into ClutterPaintNode instead of the direct
framebuffer.
* Various pieces of Wayland code now use MetaSurfaceActor
instead of MetaShapedTexture.
* MetaSurfaceActorWayland doesn't override size negotiation
vfuncs anymore
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Double negations are the spawn of the devil, and is_non_opaque() is
used like that to find out if it's opaque most often, change the
function name to see the glass half full.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
Wayland clients do this through the opaque region in the surface
actor. However X11 clients were considered fully transparent for
culling purposes, which may result in mutter painting other bits
of the background or other windows that will be painted over in
reality.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
We want to clip it away if 1) The window is fully opaque or
2) If it's translucent but has a frame (as explained in the comment
above). The code didn't quite match and we were only applying it on
case #2.
Case #1 is far more common, and saves us from pushing some drawing
that we know will be covered in the end.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/698
Make it so it returns the closest ancestry MetaWindowActor if it
is a MetaSurfaceActor.
We need this for Wayland subsurfaces, so we can support actions like
Meta+Drag on them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/604
Waking up gnome-shell and triggering JavaScript listeners of
`size-changed` every time a window was only moved was wasting a lot
of CPU.
This cuts the CPU requirement for dragging windows by around 22%.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/568
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
In MetaWindowActor creation we're setting the compositor private (i.e. the
window actor itself) of a window before creating the surface actor, and so
passing to the it a window without its compositor side set.
Since the surface actor might use the parent actor, set this before updating
the surface.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
As per commit 80e3c1d set_surface_actor has been added, meant to do different
things depending on the backend, like connecting to signals under X11.
However, the vfunc isn't ever used, making the X11 surfaces not to react to
repaint-scheduled signal.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
The commit
commit 60f7ff3a69
Author: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
Date: Fri Dec 21 18:12:49 2018 -0200
window-actor: Turn into a derivable class
made the previous instance struct a instance private struct, but didn't
remove the parent field. Since it's unused, there is no point in keeping
it around, so lets drop it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/658
