All existing users of clutter_actor_has_mapped_clones() actually want to
know whether the actor is being cloned by a visible clone, it doesn't
matter to them if that clone is attached to an actor somewhere else in
the tree or to the actor itself.
So make clutter_actor_has_mapped_clones() a bit more convenient to use
and also check the clones of the parent-actors in that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
When the wallpaper image is larger than the monitor resolution we already
use mipmapping to scale it down smoothly in hardware. We use
`GL_TEXTURE_MIN_FILTER` = `GL_LINEAR_MIPMAP_LINEAR` for the highest quality
scaling that GL can do. However that option is designed for 3D use cases
where the mipmap level is changing over time or space.
Since our wallpaper is not changing distance from us we can improve the
rendering quality even more than `GL_LINEAR_MIPMAP_LINEAR`. To do this we
now set `GL_TEXTURE_MAX_LEVEL` (if available) to limit the mipmap level or
blurriness level to the lowest resolution (highest level) that is still
equal to or higher than the monitor itself. This way we get the benefits
of mipmapping (downscaling in hardware) *and* retain the maximum possible
sharpness for the monitor resolution -- something that
`GL_LINEAR_MIPMAP_LINEAR` alone doesn't do.
Example:
Monitor is 1920x1080
Wallpaper photo is 4000x3000
Mipmaps stored on the GPU are 4000x3000, 2000x1500, 1000x750, ...
Before: You would see an average of the 2000x1500 and 1000x750 images.
After: You will now only see the 2000x1500 image, linearly sampled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1003
One of the important classes in Mutter's handling of client textures is
the `MetaShapedTexture`. This commit adds a few gtk-doc comments which
explain its purpose, with special attention to the viewport methods.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1210
When resizing an X11 window with client side decorations, the shadow is
clipped by the frame bounds so that we don't need to paint the shadow
under the opaque areas covered by the window and its frame.
When the X11 client uses the EMWH synchronization mechanism (like all
gtk-3 based clients), the actual window may not be updated so that the
actual window and it frame may be behind the expected window frame
bounds, which gives the impression of de-synchronized shadows.
To avoid the issue, keep a copy of the frame bounds as a cache and only
update it when the client is not frozen so that the clipping occurs on
the actual content.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1178https://gitlab.gnome.org/GNOME/mutter/merge_requests/1214
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
Try to bypass compositing if there is a fullscreen toplevel window with
a buffer compatible with the primary plane of the monitor it is
fullscreen on. Only non-mirrored is currently supported; as well as
fullscreened on a single monitor. It should be possible to extend with
more cases, but this starts small.
It does this by introducing a new MetaCompositor sub type
MetaCompositorNative specific to the native backend, which derives from
MetaCompositorServer, containing functionality only relevant for when
running on top of the native backend.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
We need to coordinate with MetaCompositor during pre-paint so that we
have control over whether MetaLater callbacks happen first, or the
MetaCompositor pre-paint logic.
In order to do so, make MetaLater listen to a new signal "pre-paint" on
MetaCompositor, that is called MetaCompositors own pre-paint handling.
This fixes an issue where the top window actor was calculated after the
MetaCompositor pre-paint handling, meaning the top actor being painted
was out-of-date.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Since the order of destruction during MetaDisplay tear down is a bit
unordered, there are pieces that try to destruct its compositing
dependent pieces (i.e. queued MetaLater callbacks) after MetaCompositor
has been cleaned up, meaning we need to put some slightly awkward NULL
checks to avoid crashing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
MetaCompositor is the place in mutter that manages the higher level
state of compositing, such as handling what happens before and after
paint. In order for other units that depend on having a compositor
instance active, but should be initialized before the X11 implementation
of MetaCompositor registers as a X11 compositing manager, split the
initialization of compositing into two steps:
1) Instantiate the object - only construct the instance, making it
possible for users to start listening to signals etc
2) Manage - this e.g. establishes the compositor as the X11 compositing
manager and similar things.
This will enable us to put compositing dependent scattered global
variables into a MetaCompositor owned object.
For now, compositor management is internally done by calling a new
`meta_compositor_do_manage()`, as right now we can't change the API of
`meta_compositor_manage()` as it is public. For the next version, manual
management of compositing will removed from the public API, and only
managed internally.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
While at it, fix some style inconsistencies, for now use a single
singleton struct instead of multiple static variables, and
other non-functional cleanups. Semantically, there is no changes
introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Better to have the relevant object figure out whether it is a good
position to be unredirectable other than the actor, which should be
responsible for being composited.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
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
We checked that the content size was appropriately painted in the stage,
but didn't take into account that the size of the sampled texture
region, meaning that when stage views were scaled, we'd think that we
would draw a texture scaled, as e.g. a 200x200 sized texture with buffer
scale 2 would have the size 100x100. When stage views were not scaled,
we'd apply a geometry scale meaning it'd end up as 200x200 anyway, thus
pass the check, but when stage views are scaled, it'd still be painted
as a 100x100 shaped texture on the stage, thus failing the
are-we-unscaled test.
Fix this by comparing the transformed paint size with the sampled size,
instead of the paint size again, when checking whether we are being
painted scaled or not. For example, when stage views are scaled, our
200x200 buffer with buffer scale 2, thus content size 100x100 will
transform to a 200x200 paint command, thus passing the test. For
non-scaled stage views, our 200x200 buffer with buffer scale 2 thus
content size 100x100 will also transform into a 200x200 paint command,
and will also pass the check, as the texture sample region is still
200x200.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/804https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1124
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
This fixes a case that was overlooked in
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1036 - when we
have a geometry scale > 1 and Wayland subsurfaces that have an offset
to their parent surface (which is often the case when the toplevel surface
includes decoration/shadows etc.), we have to add extra offset to their
opaque regions so they match their 'visible' location.
This is necessary as `meta_cullable_cull_out_children` moves the coordinate
system during culling, but does not know about geometry scale.
Also, remove the redundant check for `window_actor` - we only hit this code
path if a `window_actor` culls out its children.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1108
To keep consistent and avoid confusion, rename the function:
`meta_window_x11_buffer_rect_to_frame_rect()`
to:
`meta_window_x11_surface_rect_to_frame_rect()`
As this function doesn't deal with the `window->buffer_rect` at all.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
The code in `build_and_scan_frame_mask` predates the introduction of the
`MetaShapedTexture` API to get the texture width hand height.
Use the new `meta_shaped_texture_get_width/height` API instead of using
the CoGL paint texture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
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
Commit 7dbb4bc3 cached the client area when the client was frozen.
This is not sufficient though, because the buffer size might still be
lagging waiting for the buffer from Xwayland to be committed.
So instead of caching the client size from the expected size, deduce the
client area rectangle from the surface size, like we did for the frame
bounds in commit 1ce933e2.
This partly reverts commit 7dbb4bc3 - "window-actor/x11: Cache the
client area"
https://gitlab.gnome.org/GNOME/mutter/issues/1007https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
This shape region culling was wrongly implemented in f5a28aa9, as it
does not take frame offsets into account, and is also redundant, as
we already set the opaque region of the underlying surface accordingly.
The other parts were implemented in ac7aa114, the reason given in
the commit message:
```
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.
```
is wrong though - culling on X11 actors works just fine and did only
not work in Wayland sessions because of a bug that got fixed in
19814497.
In conclusion the whole part appears to be redundand and some testing
done suggests the same. Drop it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
If a opaque region is explicitly set we should not consider the surface
opaque, as that implies e.g. a shape region is set.
If no opque region is set but the texture does not have an alpha channel,
we can savely cull it out.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1082
Given that on Wayland we are pretty much guaranteed to finish MetaX11Display
setup after the MetaCompositor is enabled, we may drop the
meta_compositor_manage() x11 initialization bits, and move them into the
MetaX11Compositor subclass where it's actually needed.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
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
Instead of users fetching it via `clutter_stage_get_redraw_clip()`, pass
it via the paint context. This is helpful as it is only valid during a
paint, making it more obvious that it needs to be handled differently
when there is no redraw clip (i.e. we're painting off-screen).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1042
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 shell surface role is the one where subsurfaces may exist, and it
has direct relation to the MetaWindowActorWayland which currently has
the subsurface stacking logic.
Instead of directly finding the window actor when dealing with
subsurfaces, notify the parent surface that the subsurface state
changed, so that it can outsource the application of this information to
the role. For subsurface roles, this simply means forward upward to the
parent; for shell surface roles, this means regenerate the surface actor
layering.
This allows us to move away from accessing the window directly from the
surface, which in turn allows us to change the ownership structure of
windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
Currently when a window is requested to be unredirected, the
corresponding pixmap and texture can get cleared before the window has
been unredirected by the X server. This can result in the windows behind
showing through which causes a short flicker after showing an OSD or
notification when a fullscreen application is running.
Fix this by ensuring the texture is only cleared after the window has
been unredirected by the server.
Similarly when the window is being redirected again, the pixmap of the
window can only be requested after the redirection has been completed by
the server. This currently can happen in a different frame than the next
redraw of the actor resulting in an empty texture until the next redraw.
Fix this by queuing a redraw immediately after redirecting.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/997
By default clutter will show an actor as it is added to a parent. This
means that after we create the window actor, when it's added to the
window group, we implicitly show it. What we really want is to not show
it until the window is supposed to be shown, which happens when
meta_window_actor_show() is called, as showing prior to that, could
cause issues.
Avoid the implicit show by setting the "show-on-set-parent" property on
the window actor to `FALSE` on window actor construction.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1066
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
Some cullable implementation may have extra information about their
expected size. The main example here are surface actors which can be scaled
by geometry scale.
Add an API to overwrite the default size / untransformed check for such cases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1036
The local copy of the clip- and unobscured region are used to optimize
painting. To get correct results when the actor is scaled, thus "grows",
the corresponding regions have to "shrink", i.e. get scaled down.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1036
Scaling the `monitor_area` before texture creation was just wasting
megabytes of memory on resolution that the monitor can't display. This
was also hurting runtime performance.
Example:
Monitor is natively 1920x1080 and scale set to 3.
Before: The monitor texture allocated was 5760x3250x4 = 74.6 MB
After: The monitor texture allocated is 1920x1080x4 = 8.3 MB
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/2118https://gitlab.gnome.org/GNOME/mutter/merge_requests/1004
When building the frame mask, the current reported frame size may not
match when is actually on screen if the buffer has not been updated
yet.
So instead of getting the frame size from the meta window, deduce it
from the texture size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
Currently, `meta_frame_get_mask()` and `meta_ui_frame_get_mask()` will
return the frame mask applied to the current frame size, by querying the
frame themselves.
To be able to get the frame mask at an arbitrary size, change the API to
take a rectangle representing the size at which the frame mask should be
rendered.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
With Xwayland, the shape region is recomputed and reapplied even when
the actor is frozen to prevent the black shadows effect.
However, while recomputing the shape region, the current client size is
taken into account, rather than the size when the client was frozen,
which is ahead of the actual client size using the NET_WM_SYNC protocol.
Keep the current client area and to reuse them when the X11 window actor
is frozen for rebuilding the client mask texture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
On Xwayland, freezing actor updates on sync requests means the
server-side frame and shadows repaint will be frozen as well, which
causes the shadow to show black at times when resizing X11 clients
which support NET_WM_SYNC.
Using freeze/thaw commits prevents the content from changing, yet the
shape window still needs to be updated when frozen otherwise the
difference in shape induced by the on-going resize operation will show
as well, even if the toplevel window has its commits frozen.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=767212
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/858
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
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
clutter_paint_node_get_framebuffer() fell back on
cogl_get_draw_framebuffer() when the root node didn't have a custom
get_framebuffer vfunc. As this relies on deprecated implicit Cogl stack
API, it needs to go away, so handle this in the caller that knows more
about the context.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Just as with painting, add a pick context that carries pick related
temporary state when doing actor picking. It is currently unused, and
will at least at first still carry around a framebuffer to deal track
view transforms etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
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
This was wrongly introduced in 75cffd0ec4. As the comment above explains, we
only want to queue redraws in response to surface/buffer damage.
This triggered a full redraw when using DMA buffers on Wayland as we currently
create a new texture on every buffer_attach(), breaking partial invalidation.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/947
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
It seems that sometimes these functions are called by Javascript in
GNOME Shell during tear down. This causes segfaults and crash reports,
but without any backtraces other than the entry and exit points into
gjs.
In order to get more useful information about where these calls come
from, validate the input passed gracefully, by complaining in the log
and returning NULL values.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/926
We currently assume that the actor_animate() helper function returns
a timeline. However Clutter may skip implicit animations and simple
set properties directly, for example when the actor is hidden.
The returned timeline will be NULL in that case, and we abort when
using it as instance parameter to g_signal_connect().
Fix this by only setting up a completed handler when we are actually
animating, and complete the effect directly otherwise.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/925
`meta_surface_actor_is_obscured` implies that the actor got successfully culled
out and nothing of it will get painted. This includes that there are no clones,
no effects etc. In this cases we don't want to send frame callbacks, thus avoiding
unnecessary client work.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/918
As the first step into removing Cogl types that are covered by
Graphene, remove CoglEuler and replace it by graphene_euler_t.
This is a mostly straightforward replacement, except that the
naming conventions changed a bit. Cogl uses "heading" for the
Y axis, "pitch" for the X axis, and "roll" for the Z axis, and
graphene uses the axis themselves. That means the 1st and 2nd
arguments need to be swapped.
Also adapt the matrix stack to store a graphene_euler_t in the
rotation node -- that simplifies the code a bit as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
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
It is opaque if the texture has no alpha channel, or if the opaque
region covers the whole content.
Internally uses a function that checks whether there is an alpha
channel. This API will be exposed at a later time as well.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/734
We get implicit, thus auto-removed, transitions, then manage them
manually by stopping them and emitting "completed" signals. This doesn't
work since they are removed and freed when stopped. To be able to emit
the "completed" signal, hold a reference while stopping, so that we
still can emit the signal as before.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
There were multiple bugs present after the ClutterContent transition.
Refactor `get_image` to:
- always assume surface coordinates for the clip
- return a cairo_surface in buffer size
- make the offscreen path take size arguments, so we can
easily change the assumption in get_image
- fix some clipping bugs on the way
https://gitlab.gnome.org/GNOME/mutter/merge_requests/758
When starting standalone mutter and running using the native backend, we
always fall back on using the us pc105 keyboard layout. This can be very
frustrating if one is used to using some other keyboard layout, such as
dvorak, causing keyboard fumbling everytime when doing something with
standalone mutter.
Avoid this involuntary fumbling by having the default plugin query
localed what layout the user has actually configured the machine to
operate using. It doesn't add any keymap selection user interface, so
it'll always use the first one it encounters.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/787
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
Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.
However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.
Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.
The picking routines are still tied to painting.
When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.
CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
| | Intel | Nvidia |
| ------: | --------: | -----: |
| Moving the mouse: |
| Before | 10% | 10% |
| After | 6% | 6% |
| Moving a window: |
| Before | 23% | 81% |
| After | 19% | 40% |
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
https://gitlab.gnome.org/GNOME/mutter/issues/691
Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
https://gitlab.gnome.org/GNOME/mutter/issues/590,
https://gitlab.gnome.org/GNOME/mutter/issues/700
v2: Fix code style issues
Simplify quadrilateral checks
Remove the 0.5f hack
Differentiate axis-aligned rectangles
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
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
The MetaShapedTexture created by MetaSurfaceActor used to
be a ClutterActor, which means destruction was taken care
by Clutter.
Now that it's a plain GObject, we need to manually clean it
up.
Cleanup the shaped texture on disposal.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/753
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
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
meta_shaped_texture_update_area() is a private function that
is exposed in the public headers. It is not used anywhere
outside Mutter, and should really be in the private header.
Move it to the private header.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
Now that MetaShapedTexture is not a ClutterActor anymore, it does
not make sense to make it a MetaCullable semi-implementation. This
is, naturally, a responsibility of MetaSurfaceActor, since now
MetaShapedTexture is a ClutterContent and as such, it only cares
about what to draw.
Move the MetaCullable implementation of MetaShapedTexture to
MetaSurfaceActor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/409
By implementing ClutterContent, it is expected that
MetaShapedTexture can draw on any actor. However,
right now this is not possible, since it assumes
that the drawing coordinates and sizes of the actor
are synchronized with its own reported width and
height.
It mistakenly draws, for example, when setting an
actor's content to it. There is no way to trigger
this wrong behavior right now, but it will become
a problem in the future where we can collect the
paint nodes of MetaShapedTexture as part of other
ClutterContent implementations.
Use the allocation box passed by the actor to draw
the pipelines of MetaShapedTexture.
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
A base type shouldn't know about sub types, so let MetaDisplay make
the correct choice of what type of MetaCompositor it should create. No
other semantical changes introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
Introduce MetaCompositorX11, dealing with being a X11 compositor, and
MetaCompositorServer, being a compositor while also being the display
server itself, e.g. a Wayland display server.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
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
The MetaBackgroundActor was ignoring the unobscured area altogether,
and just painted according to the clip area. Check the unobscured
area too, as it might well be covered by client windows.
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
Saves us from using MetaCompositor API, at a point where it might not
be initialized yet. Use the same window directly, since we already
have it handy.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/672
We need to set XdndAware and XdndProxy on the stage window if running
a X11 compositor, this is not necessary on wayland.
Takes over gnome-shell code doing this initialization.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/667
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
X11 actors need to release the server data (pixmap and damage) before the
display is closed.
During the close phase all the windows are unmanaged and this causes the window
actors to be removed from the compositor, unsetting their actor surface.
However, in case a window is animating the surface might not be destroyed until
the animation is completed and a reference to it kept around by gjs in the shell
case. By the way, per commit 7718e67f all window actors (even the animating
ones) are destroyed before the display is closed, but this is not true for the
child surface, because the parent window will just unref it, leaving it around
if reffed somewhere else. This is fine for wayland surfaces, but not for X11
ones which are bound to server-side pixmaps.
So, connect to the parent MetaWindowActor "destroy" signal, releasing the x11
resources that implies detaching the pixmap (unsetting the texture) and removing
the damages.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/629https://gitlab.gnome.org/GNOME/mutter/merge_requests/660
