This is a public API change. Add device/sequence parameters to this
operation, so that window dragging and resizing can stick to one
set of pointing events of them all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Flip the switch in using MetaWindowDrag, leaving display grab
ops and a bunch other code unused. Some places checked the grab op
and/or window in complex ways, others just checked for grab existence
and should now look for clutter ones, and others already were already
doing this in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This helper object (and the whole window drag operation) will be
requested to the compositor instead of created directly, and only
one of those can exist at a time, so the compositor will also
safeguard that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since SSD X11 windows require synchronization between frame and client
windows on resizes, updates do not always happen immediately but in
control of external factors (i.e. when both windows become to have
a coherent size).
This method will be used to update the window position between
resize/sync operations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This compositor-side object will single-handedly drive a window
drag operation. Currently, this largely copies meta_display_begin_grab_op
and meta_display_end_grab_op, except grabbing is done through a
ClutterGrab instead of direct meta_backend_grab_device() calls. This
also means that the switch from passive to active keyboard grabs is
handled differently.
Currently, this object is dormant. It requires moving more code from
other places to become a fully functional replacement.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
That means before-update, prepare-paint, before-paint, paint-view, after-paint,
after-update. While yet to be used, it will be used as a transient frame
book keeping object, to maintain object and state that is only valid
during a frame dispatch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
I hit this rare error running the "x11" test from the suite locally:
(mutter:194027): Gdk-ERROR **: 18:21:52.525: The program 'mutter' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 663 error_code 9 request_code 143 (DAMAGE) minor_code 1)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
The only call from the Damage extension in use by Mutter that could
return BadDrawable is XDamageCreate(), and it's likely to be this
call. Wrap this X11 in an error trap, in order to catch possible
failures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2793>
Things like meta_compositor_destroy() and meta_compositor_add_window()
isn't intended to be used externally, and if they was, things would
probably fall apart rather quickly.
MetaCompositor also isn't introspected, meaning things that technically
belong to the compositing parts isn't easily available via some object,
but much take detours via other objects like MetaDisplay.
So move the API intended for internal usage to compositor-private.h, and
leave API that is meant to be expose in the public compositor.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As with the backend commit, this means all objects can reach the
MetaContext by walking up the chain, thus can e.g. get the backend from
the context, instead of the global singleton.
This also is a squashed commit containing:
compositor: Get backend via the context
The MetaCompositor instance is owned by MetaDisplay, which is owned by
MetaContext. Get the backend via that chain of ownership.
dnd: Don't get backend from singleton
window-actor: Don't get backend from singleton
dnd: Don't get Wayland compositor via singleton
background: Don't get the monitor manager from the singleton
plugins: Don't get backend from singleton
This applies to MetaPlugin, it's manager class, and the default plugin.
feedback-actor: Pass a compositor pointer when constructing
This allows getting to the display.
later: Keep a pointer to the manager object
This allows using the non-singleton API in idle callbacks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
Avoid some allocations, save some CPU cycles and make the code easier
to read.
Behaviourwise the only expected change is that now, if there are mapped
clones, we unconditionally choose the view with the highest refresh
rate the actor (or one of its clones) is on and don't check the
obscurred region any more.
Thus in some cases a client may receive a higher rate of frame callbacks
when obscured on a faster view while a clone is present on a slower
one. The assumption is that cases like this are relatively rare and
that the reduction of code complexity, the reduction of allocations in
`meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is
not fully obscured and has clones on other views, as well as generally
fewer lookups and less code in most common cases, compensate for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
We only support feedback-actors, such as DnD-icons, in the compositing
path at the moment.
The approach is similar to how we handle certain shell elements.
Implementations need to ensure no references to the object keep
around longer that necessary.
Arguably this should be replaced by a more robust and implicit actor
hierachy detection in the direct scanout code at some point.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2470
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2677>
meta_screen_cast_window_stream_src_set_cursor_metadata() relies
entirely on meta_screen_cast_window_transform_cursor_position()
to return the correct relative cursor position.
However, this function actually does not return the expected
values, since it does not apply the resource scale to the
transformed position.
Actually apply the cursor scale when calculating the cursor
position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2737>
Since the frames are now rendered by a separate process, we no longer
can guarantee at this point that all updates were handled. Engaging
in a new synchronous resize operation will again freeze the actor,
so sometimes we are left with a not-quite-current buffer for the
frame+window surface.
In order to ensure that the right changes made it onscreen, delay
this next synchronous resize step until the moment the surface was
repainted. This avoids those glitches, while still ensuing the
resize operation ends up in sync with the pointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Let the frames client render its own shadow. In order to do that,
avoid double painting a shadow on the compositor side, and extend
the mask area of the frame, so it does unveil the (so far)
hidden frames-client-side shadows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
There's two meanings of "frame" there! Since SSD frames are now
rendered by an external client, and there are no actual mechanism
that ensures the frame did already get painted when the client did
respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be
artifacts when resizing windows.
In order to get always the best visual result, we should actually
synchronize rendering with both the client window and the window
frame window.
This commit adds these mechanisms, so a sync alarm update is
expected on both windows until further resizes are allowed, this
ensures window and frame stay in sync, even after moving rendering
elsewhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Put the helper to use, in order to lift MetaWindow itself from this
accounting. As a bonus, the data itself now moved to the MetaWindowX11
private struct, since this may only happen with X11 windows (or its
Xwayland subclass).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
And keep track of the hierarchy separately for the Wayland protocol and
for output. Protocol state is updated immediately as protocol requests
are processed, output state only when the corresponding transaction is
applied (which may be deferred until the next commit of the parent
surface).
v2:
* Directly add placement ops to a transaction, instead of going via
pending_state.
* Use transaction entry for the sub-surface instead of that for its
parent surface.
v3:
* Use transaction entry for the parent surface again, to ensure proper
ordering of placement ops, and call
meta_wayland_surface_notify_subsurface_state_changed only once per
parent surface.
* Drop all use of wl_resource_add_destroy_listener, transactions are
keeping surfaces alive as long as needed.
v4:
* Rebase on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501
* Drop ClutterActor code from meta_wayland_surface_apply_placement_ops.
(Robert Mader)
v5:
* Rename MetaWaylandSubSurfaceState to MetaWaylandSurfaceSubState, since
the next commit adds not sub-surface specific state to it.
v6:
* Move include of meta-wayland-subsurface.h from
meta-wayland-transaction.c to .h, since the latter references
MetaWaylandSubsurfacePlacementOp.
v7:
* Drop superfluous !entry check from meta_wayland_transaction_apply.
v8:
* Rename output/protocol fields to output/protocol_state. (Jonas Ådahl)
v9:
* Use meta_wayland_surface_state_new in
meta_wayland_transaction_add_placement_op.
v10:
* Fix a few style issues per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Add internal state (starting, running, stopping), and use this instead
of MetaDisplay struct fields to determine whether to start animations.
This fixes issues when we try to animate things when shutting down.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2716>
Attaching a new buffer with a different size than the old one means
that the viewport needs to be recalculated.
Not doing this caused the viewport to be incorrectly applied when
viewport_src_rect remained the same after attaching such buffer.
Pipeline reset usually happens when applying a new viewport,
but it doesn't happen when the viewport values remain the same.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2689>
When deciding if a window should be unredirected because it was causing
fullscreen damage in the past, it was not considered whether the window
is still fullscreen. This could result in a floating window being
unredirected if it was chosen for unredirection because of
_NET_WM_BYPASS_COMPOSITOR = 1 and was previously fullscreened for >= 100
frames, long enough to change does_full_damage, before getting
unfullscreened.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2434
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2651>
Unlike the multi-view path, the optimized/single-view one doesn't check
if the surface-actor is really present on the view. That is the case
whenever it's hidden - e.g. when the window is minimized.
Fixes 3b7137cb35
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2662>
Fullscreen Wayland toplevel surfaces don't need to respect the
configured size in which case it should be shown centered on the monitor
with a black background. The black background becomes part of the window
geometry.
The surface container is responsible for correctly culling the surfaces
and making sure the surface actors are removed from the actor tree to
avoid destroying them.
The window actor culling implementation assumes all surfaces to be direct
children of said actor. The introduction of the surface_container actor
broke that assumption. This implements the culling interface in
MetaWindowActorWayland which is aware of the actor surface_container and
fullscreen state.
v2: Fix forwarding culling to surface even if there is a background.
v2: Don't alter passed geometry.
v2: Update window geometry code documentation to reflect these changes.
v2: Only use constrained rect if we're acked fullscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
Prepare for adding Wayland specific culling logic to the
MetaWindowActorWayland class by moving all the logic to the non-abstract
classes, since there will be no reason to keep the logic in
MetaWindowActor around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
A "window rect" in most places refers to the rectangle the window
corresponds to when it comes to window management. MetaWindow::rect also
refers to this window management related rectangle. However in the
geometry sync functions, it instead called what was to be the rectangle
the actor should have as "window rect", which is arguably a bit
confusing. Fix this by renaming it "actor_rect" so that it becomes clear
that it's the rectangle the actor should get on the stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
MetaWindowActor previously peeked at the number of child Actors to
determine the number of surfaces. The following commit rearranged the
tree such that MetaWindowActorWayland always has two Actors. This change
lets the subclass determine if the main surface describes the whole
window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
If we have a window that match the size (i.e. will pass the "fits
framebuffer" low level check), that doesn't mean it matches the
position. For example, if we have two monitors 2K monitors, with two 2K
sized windows, one on monitor A, and one on monitor both monitor A and
B, overlapping both, if the latter window is above the former, it'll end
up bing scanned out on both if it ends up fitting all the other
requirements.
Fix this by checking that the paint box matches the stage view layout,
as that makes sure the actor we're painting isn't just partially on the
right view.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2387
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624>
The completed signal is only emitted if the timeline actually completed
but when an actor is destroyed or removed from its parent the timeline
is stopped and not completed.
The workspace switch effect removes window actors from the window group
which destroys the timeline so on_$EFFECT_effect_stopped is never
called and the pointer to the timeline is dangling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
The workspace switch animation moves the WindowActors out of the
WindowGroup so if we shut down while the animation is playing the
WindowActors will have queued a destroy but will be disposed only after
the compositor is destroyed, leaving the WindowActor with a dangling
pointer.
Fix the issue by killing the workspace switch animation on shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
If a stage view uses an offscreen framebuffer exclusively for
rotation and a Wayland client provides pre-rotated buffers,
we should try to use scanout.
This saves us one copy more than scanout in the onscreen case,
i.e. two fullscreen copies in total.
Offscreen rotation is notably used for all 90/270 degree rotations
at the moment, as using display hardware for them is apparently
more complex than for x-/y-flips and can even have detrimental
effects on power consumption.
This can be tested with `weston-simple-egl`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2468>
This reverts an attempt at saving texture memory that was introduced
recently in 16fa2100. It was misguided because the same texture may be
needed in the next frame if a window has multiple previews visible on
screen at once (gnome-shell's overview). Keeping the mipmaps around
seems to reduce the peak render times of the overview by roughly 5%-10%.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2598>
This uses MetaCompositorViewNative to find a candidate surface for
scanout and to keep track of it separately for each view, effectively
allowing each CRTC to use a different buffer for direct scanout.
There are three parts for potentially assigning a buffer for direct
scanout at the compositor level:
1. Finding a candidate surface actor on the view (if any)
2. Attempting to assign the candidate's buffer for direct scanout
3. Updating references relating to the scanout candidate as needed
The three parts were moved in their entirety from being handled by the
MetaCompositorNative to being handled by the MetaCompositorViewNative.
As part of this transition, the logic was also slightly refactored so
that each of the three parts is handled by its own helper function.
This allowed to avoid the use of "goto" statements and hopefully make
the logic easier to read and follow.
The first part mentioned above was changed in this commit to make use
of the new meta_compositor_view_get_top_window_actor () API to get the
top window actor in the view instead of the top window actor on all
views.
The second part and third parts mentioned above weren't changed other
than being done in the context of a view instead of globally.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
All of the checks this function performed internally were already
done before calling it, making it a simple wrapper function without a
meaningful purpose.
Removing this function also reduces the chance of additional checks
being added to the MetaSurfaceActor after it is already chosen as a
scanout candidate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
This class is meant to hold logic specific to the native backend
in the context of a MetaCompositorView.
Its addition requires making MetaCompositorView inheritable, and an
addition of a virtual function which allows each compositor to create
its own MetaCompositorView instance.
In the case of the MetaCompositorNative, a MetaCompositorViewNative
is created. In all other cases, a MetaCompositorView is created.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
First, add logic in MetaCompositorView to find topmost visible
MetaWindowActor on its view, and expose it through a new API.
Then, queue an update to find the top MetaWindowActor of each
MetaCompositorView in the following cases:
1. The MetaCompositor is in its initial state.
2. The window stack order has changed.
3. A window has changed its visibility.
4. A "stage-views-changed" signal was emitted for a MetaWindowActor.
Finally, perform the queued update in meta_compositor_before_paint (),
and assert that an update isn't queued during painting. This ensures
that the top window actor in the MetaCompositorView remains up-to-date
and available to child classes of MetaCompositor throughout the entire
paint stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
The idea is that the state of the MetaCompositorView shall be
up-to-date only in specific scenarios, thus allowing operations
performed on it to be queued and aggregated to be handled in the
right time, and only if they are still necessary.
For example, in a following commit, the top window actor in each
view will be planned (if needed) only once before painting a frame,
rendering the top window actor in the MetaCompositorView potentially
stale in all other times.
Similarly, if a MetaCompositorView is destroyed before the beginning
of the frame, a queued operation to update its top window actor can be
discarded.
As an interface segragation measure, and as part of an attempt to
avoid the use of g_return_if_fail () to check the validity of the
MetaCompositorView's state in multiple places (which is still prone to
human error), the interfaces through which a MetaCompositorView is
made available would only ones where it's state is gurenteed to be
up-to-date.
Specifically, this commit gurentees that the state of the
MetaCompositorView would be up-to-date during the before_paint () and
after_paint () vfuncs exposed to child classes of the MetaCompositor.
The frame_in_progress variable will be used in a following commit to
guarantee that the MetaCompositorView's state is not invalidated during
this time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
MetaCompositorView is a class which contains compositor logic
specific to ClutterStageViews.
Each MetaCompositorView is "attached" to a ClutterStageView as an
opaque pointer using g_object_set_qdata_full (), and is freed when
the ClutterStageView is destroyed. This ensures that the lifetime of
the MetaCompositorView can't extend beyond the lifetime of its
ClutterStageView.
In a following commit, MetaCompositorView will be expanded to allow
keeping track of the top MetaWindowActor located on each
ClutterStageView.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
Although mipmapping is still slower than not mipmapping, commit 16fa2100
simplified N synchronous draw calls per texture tower into just one. So
it's more efficient now, and four years have passed since the throttling
was introduced so people also have better hardware as well as mutter being
generally faster than it used to be. So I am happy to effectively revert
commit c9c32835.
This means antialiasing will remain consistent rather than popping in and
out of existence.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/403
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2538>
With `META_MONITOR_TRANSFORM` values matching their `WL_OUTPUT_TRANSFORM`
counterparts, the definition from the Wayland spec applies: the
`META_MONITOR_TRANSFORM` value tells us how the output was rotated
and that the buffer was drawn by the client to compensate for that.
The matrix describes the transformation from surface- to buffer-
coordinates, so the operation we need here is the same one that
the client applied (not from buffer- to surface-coordinates, i.e.
the inverse).
While on it fix `FLIPPED_90` and `FLIPPED_270` to use the correct
axes: flip on the x-axis, rotation on the z-axis.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
`clutter_actor_set_child_at_index()` is far from a no-op, even if
the current index is equal to the new one - presumably for good
reasons. For the use-case here we want it to be a no-op though, so
skip calling it if the index already matches.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501>
Unparenting the surface actor when the subsurface object is destroyed
has several issues:
- subsurface actors can be unparented while a close animation is
still ongoing, breaking the animation for e.g. Firefox.
- adding and removing the actor to/from the parent is not handled in
one place, making the code harder to follow.
- if the destroyed subsurface had children of its own, they potentially
stick around until a surface-tree rebuild. This makes the Firefox
hamburger menu not close with the "compositor" backend.
Move the unparenting back to
`meta_window_actor_wayland_rebuild_surface_tree()` and instead just
notify the parent of a state change, if it still exist. This will ensure
a correct mapping between the subsurface node tree and the flat surface
actor list. In case of the closing animation the parent will already be
removed and the call is skipped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501>
The Cogl feature was removed a while back, while Clutter just hard coded
it to TRUE. Lets remove the confusion that GLSL isn't supported and just
remove the (dead) fallback paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2015>
Add `sync_effects_completed()` and `verify_view()` in
order to allow Wayland test clients to trigger verifications
and add convenience functions to use them to client-utils.
Notes:
- `sync_effects_completed()` works in two stages in order
to ensure it doesn't race with window effects. By the time
`sync_effects_completed()` is processed, an effect could
already have ended or not yet been scheduled. Thus we
defer a check for pending effects to the next paint cycle,
assuming that by then they should have been scheduled.
- `meta_ref_test_verify_view()` internally triggers the
`paint` signal for the stage which is why it can not be run
in the after-paint signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
The compositor currently only updates the topmost window actor that is
visible to it after stacking changes. The visibility of a window actor
to the compositor however might only change via the display idle queue
after the stacking changes. This could then lead to the topmost window
actor being assumed to be NULL on Wayland after switching from an empty
workspace or when opening the first window on an empty workspace. The
result of this is direct scanout being disabled in these cases.
To fix this also trigger the update when the visibility of windows
changes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2269
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2413>
Some windows span the entire screen but still use transparency, such as
the desktop window of Nemo. When these windows were used for direct
scanout, the transparent areas would turn black and nothing else would
be rendered.
In addition to checking the surface for opaqueness, for X11 windows also
the window actor itself has to be checked, because its opacity might
have been changed via _NET_WM_WINDOW_OPACITY.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2263
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
This replaces the API to get the topmost surface actor with an API to
get the surface actor that could be a candidate for direct scanout. The
advantage of this is that it allows X11 and Wayland specific
restrictions for these actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
When we get passed a "snippet" to the shaped texture, it's added as a
pipeline layer snippet to change how the source texture is sampled. When
we draw from a texture tower however we have allocated regular textures
which doesn't need any special layer snippet, so create separate
pipelines for those that doesn't use that snippet.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/528
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2278>
Before scanning out the surface of a native client we have
to check the following attributes that influence the
relationship between buffer and the defined result on screen:
- buffer scale
- buffer transform
- viewport
In the future we can loose these checks again in cases where the
display hardware supports the required operations (scaling, cropping
and rotating).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2276>
Since the introduction of ClutterGrabs, MetaDnd now no longer gets
notified about input events on the stage during grabs (for example while
the alt-tab popup is shown) and thus can't move the grab feedback actor
anymore.
To fix this, forward events to MetaDnD directly from
meta_display_handle_event() when a ClutterGrab is in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
Wayland event processing and WM operations are themselves outside the
ClutterGrab loop so far. Until this is sorted out, these pieces of
event handling have got to learn to stay aside while there is a
ClutterGrab going on.
So, synchronize foci and other state when grabs come in or out, and
make it sure that Wayland event processing does not happen while
grabs happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
In order to support dynamic imports, gjs added an implicit mainloop
that can drive the main context independently from other mainloops
like the one from GApplication or MetaContext.
That means that sources can now get dispatched to the main context
from the moment the plugin is started, resulting in a crash as the
association between compositor and plugin manager doesn't exist until
meta_plugin_manager_new() returns.
Make sure this doesn't happen by only starting the plugin after
meta_plugin_manager_new() has returned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2242>
If a Wayland subsurface is the topmost actor, consider in for
scanout as well. This will extend our scanout capabilities to apps
like Firefox
While on it, correct a unnessary type check to a NULL check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
On Wayland a window actor may have more than one surface actor,
most importantly when subsurfaces are used.
Add a new function to request the one which is at the top -
it will be used in the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
When rendering to a buffer that is not the stage view buffer, we can not
know where the buffer will be displayed on the screen. As a result we
also can not know what translation would need to be applied to culling.
This was causing glitches when the gnome-shell magnifier was applying
offscreen effects. ClutterOffscreenEffect causes MetaWindowGroup to be
rendered to an offscreen buffer at an offset, because it draws to a
slightly larger texture with an accordingly translated origin. This
translation then later is canceled out again when the offscreen buffer
is drawn. To meta_actor_painting_untransformed() however which only sees
the translation used when drawing to the buffer this looked like the
window group was being rendered at the offset. This then lead to
redraw_clip getting translated accordingly, resulting in wrong
coordinates used for culling.
Similarly this was leading to issues when taking area screenshots while
at 1x zoom.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1678
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4876
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2080>
Since the completion callback (on_switch_workspace_effect_complete) sets
priv->tml_switch_workspace1 to NULL, the unref was trying to unref NULL,
and the reffed ClutterTimeline was not getting unreffed.
This could be triggered by rapidly switching workspaces, switching again
before the animation of the initial switch was done.
Found while working on #2038.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2120>
This can happen if a texture was newly assigned to the actor, but the
unobscured region hasn't been updated yet. Without bailing here, the
actor would display correctly via direct scanout, but other parts of
mutter would continue considering it obscured, which would e.g. result
in no frame callbacks getting sent for its surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1636
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2112>
Previously we chose to only anti-alias texels inside the boundary
(`clip_radius - 1.0`) but zoomed in you could see it was slightly smaller
than the correct curve (#2024).
Similarly if you choose to only anti-alias texels outside that edge
(`clip_radius + 1.0`) then you'd get an overly convex curve that doesn't
match up with the straight line sections.
So now we anti-alias texels that intersect the circle boundary, regardless
of which side they are mostly on. For efficiency we define "intersect" to
mean any texel whose center is within 0.5 of the theoretical edge.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2024
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2102>
When grabbing the devices, there's no error paths that would quit
late enough that both pointer and keyboard would need ungrabbing,
so the keyboard checks were dead code.
Fix this by dropping the boolean variable checks, and adding goto
labels to unroll the operation properly at every stage.
CID: #1418254
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
Analogous to `get_image()` this returns a `ClutterContent` for a
given `MetaWindowActor`. This can be used to implement window
effects without a roundtrip from GPU to CPU memory.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1893>
We fetch a frame clock that we schedule update on when queuing
_NET_WM_FRAME_DRAWN events. In some situations this frame clock is the
one from the stage, and if there are multiple hotplugs in a row, we
failed to update it as there were no stage views changes on the window
actor itself. As an actor updates the stage views list on layout, When a
queue_frame_drawn() call was done (typically from an X11 event) after a
second hotplug, it'd attempt to schedule an update on the frame clock
from the previous hotplug, as it didn't get notified about any
stage-views changes since for itself there was none.
Fix this by not caching the frame clock at all and just fetch it every
time.
In the majority of cases, this fetching means iterating over a very
short list (most often a single entry, rarely more), so it's very
unlikely to be of any relevance. The only situations where it might be a
heavier operation is the short time between a hotplug and a layout, as
it will attempt to traverse up to the stage to find a clock, but that's
likely only a few levels, so even that is unlikely to be an issue.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4486
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1947>
This was introduced by accident in commit 1467b6b02a
y-inverted textures in combination with shape masks appear to
be only commonly used with EGLstreams. However, as we draw the
shape mask ourselves, we don't want to apply the y-invert to it
as testified by the left over `cogl_pipeline_set_layer_matrix()`.
Note that we still allow to apply viemports and buffer transforms,
as the Xwayland mode setting emulation may use it (in fact only
the former, but it probably does not hurt to leave the later as well).
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1792
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1937>
This code sneaked unconditionally, even though we can disable
tracing code with -Dprofiler=false. Add some COGL_HAS_TRACING
checks so that this code is also optionally built.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1951>
When a viewport source rect or destination size is set, `stex->dst_width`
gives us the the cropped and/or scaled size. At this step, we need the
uncropped/unscaled size however.
Note: this is only ever relevant if buffer transform and viewport are
used together - otherwise the values are the same.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1836>
The shadow size is factored into the paint volume MetaWindowActorX11
returns in its get_paint_volume() vfunc override, so we should
invalidate the paint volume every time that shadow might change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1829>
When using buffer transforms and viewports together, we currently
apply the transformation (read: rotation) first, resulting in
wrong buffer coordinates for viewport source rects.
Flip the order in whitch we apply our matrix transformations.
This can be tested e.g. via:
`weston-simple-damage --use-viewport --transform=flipped-180`
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1832>
Currently when reordering subsurfaces, we un- and reparent all child
actors of the window actor. This is unnecessarily wasteful and
triggers bugs in clutter. While the underlying issue should be fixed
eventually, simply reorder the actors with the tools clutter provides
us with, avoiding those bugs and likely being faster as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1831>
When the texture size is invalidated using `invalidate_size()`, the new
size will only get calculated the next time `update_size()` is
called. This happens e.g. in `meta_shaped_texture_get_preferred_size()`
via `ensure_size_valid()`.
`update_size()` can chain up to `clutter_content_invalidate_size()`
as well as emitting a `size-changed` signal. If this happens during
layout, the result is a 'change the layout conditions during layout'
issue, causing heavy breakage in e.g. the Shell overview.
To fix this, expose `ensure_size_valid()` as API so callers can make
sure the texture has a valid size without creating redundant size
invalidations calls.
Note that if a buffer with a new size is attached we already trigger
`update_size()` explicitely, avoiding such situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1799>
