At the end of the sync_actor_geometry function the window buffer_rect
and the WindowActor position and size are the same and consistent.
Call the virtual method at the end and let the implementations look at
either the buffer_rect or the actor position/size itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3404>
In some cases the window is not mapped when the geometry changes.
Without the mapped window the surfaces are not mapped either and don't
have a sensible allocation.
This patch makes sure we abort syncing the geometry if the window is not
mapped and also make sure we sync geometry when the actor eventually
does get mapped.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3152
Fixes: 8f4ab53bd ("window-actor/wayland: Ensure to use allocation for black background check")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3401>
Group all the three config files from clutter/cogl/meta into one
and also remove unnused configurations and replace duplicated ones
This also fixes Cogl usage of HAS_X11/HAS_XLIB to match the expected
build options
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3368>
Currently, json-glib is used for two things:
- For loading scripts, nothing seems to use that in real life other
than some tests
- For debugging paint nodes
For now, the PR drops the first use case and only require json-glib
if it is a debug build
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3354>
- Make Texture a parent GObject class and move the vtable funcs as vfuncs
instead of an interface as we would like to have dispose free the TextureLoader.
- Make the various texture sub-types inherit from it.
- Make all the sub-types constructors return a CoglTexture instead of their respective
specific type. As most of the times, the used functions accept a CoglTexture,
like all the GTK widgets constructors returning GtkWidget.
- Fix up the basics of gi-docgen for all these types.
- Remove CoglPrimitiveTexture as it is useless: It is just a texture underhood.
- Remove CoglMetaTexture: for the exact same reason as above.
- Switch various memory management functions to use g_ variant instead of the cogl_ one
Note we would still want to get rid of the _cogl_texture_init which is something
for the next commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
The surface actors may not have a valid allocation when running the
test. The preferred height, which `clutter_actor_get_size()` returns
in that case, can be wrong in certain cases, making us not add the black
background when it's actually needed.
Query the allocation instead, even at the expense of additional
relayouts.
While on it, sneak it some small cleanups.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3024
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3310>
It's the 10 bit equivalent to NV12 and uses the same layout as P016, i.e.
16 bit components with the lowest 6 bits set to 0 (padding), allowing us
to use 16 bit "subformats".
Thus adding support is quite trivial as we can reuse the NV12 shader.
The format is widely supported in decoding and display hardware (on Intel
since Kaby Lake), as well as modern codecs (AV1, VP9, HEVC) and has
visible quality advantages over NV12.
Note that the additional colors are lost if composited to a 8 bit RGB
framebuffer. Switching between direct scanout and compositing can thus
cause quality differences. This is no new phenomena, however, as the
same is the case already for e.g. GL clients using 10 bit formats -
including video players.
Also note that P012 and P016 could trivially added as well - it's not
done here as they are uncommen and thus hard to test.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
These shaders can be used for similar formats with other component
sizes since the values are represented as floats. So whether the source
value was stored in 8bit, 10bit or 16bit doesn't matter - the driver
will covert it for us.
Thus use a Weston-inspired, more general naming scheme.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
When the actor gets a new "main" surface assigned, it adds the
new surface to the stack of surface actors, but forgets to remove
the old one.
This stale pointer in the array may cause invalid reads and crashes
after the assigned surface is disposed, e.g. when destroying the
MetaWindowActor tries to disconnect signals from all accounted
surface actors.
Fixes: 9a2c8b2592 ("window: Add suspend state")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3252>
Commit 3bfcb6d1 fixed the check for tiling via keybindings, but
ignored a subtle edge case when tiling with the pointer: The
monitor used for tiling is the monitor with the pointer, which
is not necessarily the one that contains the largest part of the
window.
That is, the correct monitor to check against depends on the
context where the function is called. We can either figure
it out automatically via the current window drag, or make it
a parameter.
The latter is clearer, because the callers already decide which
monitor to use for tiling anyway.
Fixes: 3bfcb6d1b9 ("window: Fix portrait orientation check for tiling")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3248>
These snippets are retrieved anew every time a window is resized. But
callers never modify them, they're effectively read-only so cache them
at the place of creation.
This is required to convince the pipeline hash that each reuse of the
same snippet really is the same snippet and so the pipeline is unchanged.
`CoglPipelineSnippetList` only does shallow comparisons and there's no
need right now to reimplement it as a deep comparison.
This eliminates the log message:
> Over 50 separate %s have been generated which is very unusual,
> so something is probably wrong!
which isn't actually a leak but more a warning about wasting time.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6958
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3224>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
The 'suspend state' is meant to track whether a window is likely to be
visible any time soon. The hueristics for this are as follows:
* If a window is hidden, it will enter the 'hidden' state.
* If a window is visible, and unobscured, it will enter the 'active'
state.
* If a window is visible, but obscured by another window, it will enter
the 'hidden' state.
* If there is a mapped clone of a window, it will enter the 'active'
state.
* If the window has been in the 'hidden' state for 3 seconds, it will
enter the 'suspended' state.
This will eventually be communicated to Wayland clients so that they can
change their behaviour to e.g. save power.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3019>
This is something the compositor could now track by itself, instead of
being pushed through events. It also makes more sense to do this directly
when the grabbing conditions change, as opposed to the next event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
This splits culling into two different phases to move unobscured region
culling to pre-paint to fix#2680. This is needed as direct scanout
skips the paint phase altogether, but the pre-paint phase always runs as
it's used for selecting the direct scanout surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3127>
Nowadays, all our MapNotify event handling happens already prior to
the MetaCompositorX11 handling of XEvents. It does not make sense to
channel these events again through the backend, at best all it could
lead to is double handling of the same events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
To be able to later support more complex YUV formats, we need to make
sure that MetaShapedTexture (the one who will actually render the
texture) can use the MetaMultiTexture class.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Daniel van Vugt <daniel.van.vugt@canonical.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>