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>
If only a viewport destination size is set, the noop viewport has
to take the buffer scale into account.
If a viewport source but no viewport destination size is set, the
destination size is that of the viewport source, not of the whole
texture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1786>
The order of which function argument expressions are executed is
undefined, so don't rely on this for setting the background colors, as
it results in different colors on different architectures.
For example, it has been observed that the order of execution is
reversed comparing x86_64 and aarch64, making these two architectures
having different background color.
Fix this confusion, and also reproduceability in future reference tests,
by making the order of execution predictable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The sync ring has an API about "frames", where it is notified about
the end of frames. However, its "insert wait" call is done before
updates, meaning that some "insert waits" will never see the "after
frame" if there was no frame drawn. This will cause mismatching in the
frame counting, causing freezes in the synchronization until something
else triggers an actual frame, effectively "unfreezing" the sync ring.
Fix this by not only notifying the sync ring about frames when there
were actual frames drawn, but also on plain updates which didn't result
in a drawn frame.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1754>
This concerns only the cases when the presentation timestamp is received
directly from the device (from KMS or from GLX). In the majority of
cases this timestamp is already MONOTONIC. When it isn't, after this
commit, the current value of the MONOTONIC clock is sampled instead.
The alternative is to store the clock id alongside the timestamp, with
possible values of MONOTONIC, REALTIME (from KMS) and GETTIMEOFDAY (from
GLX; this might be the same as REALTIME, I'm not sure), and then
"convert" the timestamp to MONOTONIC when needed. An example of such a
conversion was done in compositor.c (removed in this commit). It would
also be needed for the presentation-time Wayland protocol. However, it
seems that the vast majority of up-to-date systems are using MONOTONIC
anyway, making this effort not justified.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
The cache had the size 9, which was "big enough" in the past, but when
more ways pipelines could be constructed, the size was not enough. The
need to increase the cache size was hard to spot though, since adding
pipeline flag didn't give any hints about the cache being directly tied
to these flag values.
So, when enough flag bits were set when attempting to retrieve and put a
pipeline in the cache, it'd instead overwrite some arbitrary stack
memory, which would sooner or later result in a memory corruption
induced crash. Valgrind could not detect this particular memory
corruption, as it messed up stack memory, not e.g. freed heap memory, so
it instead got confused and thought plain stack values were unreadable.
Fix these two issues by making the cache size the combination of all
pipeline flags + 1, so that we can safely put any flag combination in
the cache.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1747>
GObject signals pass the emitting GObject as the first argument to
signal handler callbacks. When refactoring the grab-op-begin/end signals
to remove MetaScreen with commit 1d5e37050d,
the "screen" argument was replaced with a "display" argument instead of
being removed completely. This made us call the signal handlers with two
identical MetaDisplay arguments, which is very confusing and actually
wasn't handled in a grab-op-begin handler in gnome-shell.
So fix this by not adding the MetaDisplay as an argument to those
signals, GObject will take care of that for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1734>
We're going to round the workspace backgrounds in the new overview for
gnome-shell 40.
So far corner-rounding was only possible for StWidgets because the
rounded clipping was done using cairo drawing. We now need rounded
clipping for ClutterActors too because backgrounds are drawn using
ClutterActors (or more specifically a ClutterContent). To implement
that, first a ClutterOffscreenEffect subclass together with a fragment
shader from GSK (see gskSetOutputColor() [1] in the GSK GL renderer
code) was investigated, and while that was generic and worked quite
well, it was extremely slow for the case of drawing wallpapers because
of all the FBOs that had to be allocated.
This is the new, more performant approach: Use the same fragment shader,
but perform the rounded clipping right in MetaBackgroundContent while
we're painting the wallpaper. This has almost no performance impact,
with the downside of not being a generic solution.
To allow for rounded clipping not only at the edges of the wallpaper,
but using any given bounding rectangle, the API exposes not only the
radius, but also a bounding rect.
[1] https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gsk/resources/glsl/preamble.fs.glsl
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1717>
Ensure we issue a motion event for the current pointer position,
as there might be situations where compositor modals get X grabs
from other clients stacked on top, or missed events in between
otherwise.
Ensure the Clutter state is still up-to-date afterwards here. This
replaces some sync_pointer() calls done in GNOME Shell code, always
done after modality changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
Do these Wayland operations (that apply on both native and nested backends)
in the MetaCompositorServer subclass. We want to add more backend specific
behavior here in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
Technically this is still wrong if the source actor or dnd actor are
transformed in other ways. However geometry scale is the by far most
common case and we currently lack convenience API in Clutter to
easily compute the right values.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1683>
Mutter freezes Xwayland commits when resizing windows, and thaw them in
the window actors' after_paint() for X11.
Yet, after_paint() could be never called, as when a new window is mapped
while the overview is active in gnome-shell.
As a result, the content of the X11 window will remain invisible to the
overview.
Add a new window actor API to tell whether commits can be frozen. For
Wayland window actors, this always return FALSE, whereas for X11 window
actors, it checks whether the Clutter actor is mapped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1678>
The monitor texture is the final background image. It doesn't need to
have any alpha channel. Cross-fades (which is the process of rendering
*into* the monitor texture) still work just fine.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1665>
Just because of implementation details, this is only relevant to Wayland,
and is done via ::effects-completed handlers there. Ideally, Clutter should
notice by itself about effects starting, finishing, and affecting picking.
Doing this in generic code seems slightly cleaner in the interim.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
Assert that the region is created, thus we passed a valid enum value
to the get_scaled_region() function. Fixes:
../../../../Source/gnome/mutter/src/compositor/meta-surface-actor.c: In function ‘get_scaled_region’:
../../../../Source/gnome/mutter/src/compositor/meta-surface-actor.c:113:10: warning: ‘scaled_region’ may be used uninitialized in this function [-Wmaybe-uninitialized]
113 | return scaled_region;
| ^~~~~~~~~~~~~
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1624>
In case we only have a single view (or there's only one view left to
check and the actor is visible on previous views) we can take a short-
cut, saving a region allocation and some calculations.
While on it, declare float numbers in '.f' style to make them more
recognizable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1596>
Our main use case of `is_obscured()` is frame callback emission.
Since we now support stage views running at differt speeds, we
need to know whether an actor is visible on a specific stage view
in order to schedule frame callbacks accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
We want the bounding box so `ceilf` seems more appropriate. It was
only written using `roundf` before as a workaround for inaccuracies
coming out of `clutter_actor_get_transformed_size` that would have
tricked `ceilf` into landing on the wrong integer. But that's since
been fixed by 67cc60cbda so we can use `ceilf` now.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1532
Because clones may not have identical geometry to their source actors.
So we can't use the geometry of the source actor to decide to take the
more optimized (more clipped) path.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1480
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
A boring one, with the exception that row and column needed to be
swapped. For the sake of consistency, the variable names were also
synchronized with the values they hold, so e.g. xy → yx, etc.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Ideally, we would use Graphene to do that, however as of now Graphene
lacks these APIs so we still need these helpers. Since we're preparing
to get rid of CoglMatrix, move them to a separate file, and rename them
with the 'cogl_graphene' prefix.
Since I'm already touching the world with this change, I'm also renaming
cogl_matrix_transform_point() to cogl_graphene_matrix_project_point(),
as per XXX comment, to make it consistent with the transform/projection
semantics in place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Mutter itself is versioned now, so passing the version information
to the plugin is redunant now: The version is already determined by
linking to a particular API version (gnome-shell) or by installing
to a versioned plugin path (external plugins).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1473
This reverts the commits 372d73e275 and 1d20045247 - the special
case for alpha-less textures could only happen on Wayland, but now
the opaque region is also set in those cases.
This commit saves us some allocations, simplifies the logic a bit and
makes sure culling uses the same opaque region as our painting paths.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1463
Just like we used to before 30809665d8.
Because in some cases `clip_region` is able to shave off an extra pixel
from the edge of the redraw rectangle(s). And not shaving that off was
making the background rendering inconsistent with shaped-texture, causing
occasional off-by-one artefacts. Now both shaped-texture and
background-content agree on the clip region again that doesn't happen.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1443https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1464
Using opaque painting paths can have a big impact on painting performance.
In order to easily validate whether we use the opaque paths, add a opaque
(green) or blended (purple) overlay over painted areas if the
`META_DEBUG_PAINT_OPAQUE_REGION` `MetaDebugPaintFlag` is set.
You can do so in `lg` via:
`Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)`
This can be helpful for application developers, as previously it was not
trivial to check whether e.g. Wayland or X11 opaque regions where
properly set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
When in the overview culling via `self->clip_region` is unavailable.
The region is `NULL` because the paint call has not originated from a
`WindowGroup`, because the overview does not use `WindowGroup`.
So the main wallpaper was being painted in full while in the overview.
That's a waste of effort because `redraw_clip` is going to be used to
stencil/scissor out only the parts that are changing. We don't need to
paint *most* of the wallpaper, only the parts behind anything changing.
For the overview this reduces GPU power usage (intel_gpu_top) roughly
10% and reduces render times almost as much.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
`meta_background_content_paint_content` was mixing two different
coordinate systems in `actor_pixel_rect`. It was initialized with
actor-local coordinates and then `if (self->clip_region)` would be
treated as stage coordinates. This worked because `self->clip_region`
was only non-NULL outside of the overview where both coordinate systems
were the same. So it always got the right answer, possibly by accident.
In order to enhance the function however we will need to know which
coordinate system we're working in, so now we make it explicit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
Commit 510cbef15a changed the logic in `handle_update()` for X11 window
actors to return early if the surface is not an X11 surface.
That works fine for plain Xorg, but on Xwayland, the surface is actually
a Wayland surface, therefore the function returns early before updating
the drop shadows of server-side decorations for X11 windows.
Change the test logic to restore drops shadows with Xwayland windows.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1384
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1358
That was obviously always the intention, but it didn't work when the
display was scaled. My 3840x2160 monitor with a 3840x2160 texture was
being rendered with LINEAR filtering.
It seems the `force_bilinear` flag was TRUE when it should be FALSE.
Because a texture area that's an integer fraction of the texture
resolution is still a perfect match when that integer is the monitor
scale. We were also getting:
`meta_actor_painting_untransformed (fb, W, H, W, H, NULL, NULL) == FALSE`
when the display was scaled. Because the second W,H was not the real
sampling resolution. So with both of those issues fixed we now get
NEAREST filtering when the texture resolution matches the resolution it's
physically being rendered at.
Note: The background texture actually wasn't equal to the physical monitor
resolution prior to January 2020 (76240e24f7). So it wasn't possible to do
this before then. Since then however, the texture resolution is always
equal to the physical monitor resolution.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1346
It doesn't take all children - subsurfaces in this case - into
account, thus creating glitches if subsurfaces extend outside
of the toplevel surface.
Further more it doesn't seem to serve any special purpose - it was
added in f7315c9a36, a pretty big commit, and no discussion was
started about the code in question. So it was likely just overlooked
in the review process.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/873
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1316
gnome-shell displays workspace previews at one tenth scale. That's a
few binary orders of magnitude so even using a LINEAR filter was
resulting in visible jaggies. Now we apply mipmapping so they appear
smooth.
As an added bonus, the mipmaps used occupy roughly 1% the memory of
the original image (0.1 x 0.1 = 0.01) so they actually fit into GPU/CPU
caches now and rendering performance is improved. There's no need to
traverse the original texture which at 4K resolution occupies 33MB,
only a 331KB mipmap.
In my case this reduces the render time for the overview by ~10%.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1416https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1347
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The repaint callbacks are not tied to repaint, thus a bit misleading.
What the functionality in the pre/post-paint callbacks here cares about
is when actually painting; the non-painting related parts has already
moved out to a *-update signal.
This also renames the related MetaWindowActorClass vfuncs, to align with
naming convention of the signals that it listens to.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Instead of going via MetaCompositor to know about when we updated
(confusingly named post-paint), use the new stage signal directly.
Note that this doesn't change the time frame callbacks are dispatched;
it's still not tied to actual painting even though it seemed so before
given the function names.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We'd emit multiple "presented" signals per frame, one for "sync" and one
for "completion". Only the latter were ever used, and removing the
differentiation eases the avoidance of cogl onscreen framebuffer frame
callback details leaking into clutter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The vfunc was not tied to "paint", but was used by MetaWindowActorX11
as part of the "update" mechanisms. In order to make that more clear,
special case it in MetaWindowActorX11 by type checking the surface
actor, handling the case without MetaSurfacActor abstraction.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The synchronization must happen no matter the painting, as it in itself
might result in reported damage, making the stage actually painted. Thus
move it out of the "pre-paint" handler, to something explicitly not tied
to the painting itself - ClutterStage::before-update.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Instead of the 'pre-paint' signal on MetaCompositor, rely directly on
the 'before-update' signal on the stage. A reason for this is that the
callback should not only invoked in connection to painting, but updating
in general. Currently the 'pre-paint' signal is emitted no matter
whether there were any painting or not, but that's both misleading and
will go away.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The MetaLater functionality needs to make sure an update is scheduled so
that it can run its callbacks etc. This used a ClutterTimeline (which is
an object more or less meant to drive animations markers, frames etc)
just to keep the master frame clock running. We're moving away from a
single master clock, so just schedule updates directly instead, with the
newly exposed API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
