Since the damage history region is tracked per-view, all the regions it
includes should be inside the current view anyway, so don't
unnecessarily intersect that region with the view.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since we now check for the buffer age before setting up the
fb_clip_region, that region will be set to the full extents of the view
in case the buffer age is invalid. This in turn means we don't have to
do this again later and can simply fill the damage history with the
fb_clip_region that's already set for us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since a NULL redraw_clip means that a full view redraw should be done
and an empty redraw clip may never be set (see the width/height checks
in clutter_stage_view_add_redraw_clip()), the fb_clip_region should
always be set to a reasonable region that's either the whole view or
individual regions inside the view.
So make sure that's actually the case by warning and that the
fb_clip_region isn't empty, which allows dropping another few lines of
code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Right now we're checking for the DISABLE_CLIPPED_REDRAWS debug flag
after creating the fb_clip_region and adjusting the redraw_clip. That
means that if may_use_clipped_redraw was TRUE, the redraw_clip will
still be set to the region and thus cause the stage to only be partially
redrawn. Since we don't push a clip to the framebuffer though
(use_clipped_redraw is now FALSE), parts of the view will get corrupted.
To fix that, disable clipped redraws right away if the debug flag is
set. This also allows removing the may_use_clipped_redraw bool and
replacing it entirely with use_clipped_redraw.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
We already have a better way to paint the redraw clip: Painting the
damage region paints the individual rects of the clip region and not
only the bounding rect.
So stop painting an outline around the redraw clip bounding rect when
CLUTTER_DEBUG_REDRAWS is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
While this is meant as an optimzation to only use the scissor clip and
not the stencil buffer if there's only one clip rectangle, it's not
needed since this optimization is going to be applied to region clips
anyway inside _cogl_clip_stack_gl_flush() (see cogl-clip-stack-gl.c).
So remove the unnecessary optimization here and rely on cogl-clip-stack
to do it for us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
This was introduced with commit 9ab338d7b6 because the clipping of
fractionally scaled redraws caused glitches, it seems like this is no
longer needed nowadays, so let's remove it.
This should make obscured region culling work a bit better for
fractionally scaled framebuffers because because we overdraw a slightly
smaller region than the actually damaged one. We still do overdraw
though since the clipping region is stored using integers and thus
any non-integer values have to be extended to the bounding rect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
It doesn't make sense to set the redraw clip when painting the stage if
clipped redraws are disabled. That's because when visualizing the redraw
clip and any new redraws are clipped, the old visualiziations would
remain visible, leaving multiple confusing rectangles on the screen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
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
It's very useful to have common functions for easily creating a monitor
test setup for all kinds of tests, so move create_monitor_test_setup()
and check_monitor_configuration() and all the structs those are using to
monitor-test-utils.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
We're going to move some structs from monitor-unit-tests.c to
monitor-test-utils.h and some names are currently clashing with the
struct names here, so rename those to be specific to the
MonitorStoreUnitTests.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
check_monitor_test_clients_state() is a function that's only meant to be
used in the monitor-unit-tests, and since we're going to move the
functions for creating MonitorTestSetups into a common file, this
function is going to be in the way of that. So move the checking of the
test client state outside of check_monitor_test_clients_state().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
We're going to move the functions for building MonitorTestSetups to the
common monitor-test-utils.c file.
To make building test setups a bit more straightforward in case no
TestCaseExpect is wanted, change create_monitor_test_setup() to take a
MonitorTestCaseSetup instead of a MonitorTestCase as an argument.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
Commit e06daa58c3 changed the tested values to use corresponding valid
enum values instead of negative ones. Unfortunately that made one value
become a duplicate of an existing one and also in part defeated the original
intention of checking the implementation of
`meta_output_crtc_to_logical_transform`.
Use `meta_monitor_transform_invert` to fix both shortcomings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1242
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
Since we're now connecting to one more signal of MetaWaylandOutput, keep
signal connections in one place and move connecting the
"output-destroyed" signal to surface_entered_output() and disconnecting
it to surface_left_output().
This also allows us to use the "outputs_to_destroy_notify_id" as a
simple set and rename it to "outputs".
While at it, also use g_hash_table_destroy() instead of
g_hash_table_unref() since destroy is more clear than unref and does the
same thing in this case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
When hotplugging a new monitor, we recreate all the MetaWaylandOutputs
and need to emit leave events to the surfaces for the old wl_outputs and
enter events for the newly created ones.
There's a race condition though: We might update the monitors a surface
is on (and thus emit enter/leave events for the wl_outputs) before the
Wayland client is registered with the new wl_output (ie. the
bind_output() callback of MetaWaylandOutput was called), which means we
don't send an enter event to the client in surface_entered_output().
Since MetaWaylandSurface now has the MetaWaylandOutput in its outputs
hashtable, it thinks the client has been notified and won't send any
more enter events.
To fix that, make MetaWaylandOutput emit a new signal "output-bound"
when a client bound to the output and make all surfaces which are on
that output listen to the signal. In the signal handler compare the
newly added client to the client the surface belongs to, and if it's the
same one, send an enter event to that client.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
The "output-destroyed" signal is used for notifying MetaWaylandSurfaces
that an output they are shown just got invalid (for example because a
monitor hotplug happened).
While we delay the destroying of outputs by 10 seconds since commit
1923db97 because of a race-condition, it doesn't make sense to wait 10
seconds until we let surfaces know that an output was destroyed.
So move the emission of the "output-destroyed" signal to
make_output_inert(), which is called before we start the 10 seconds
delay.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
When tiling, we want to set the tile monitor. To not have to do this
from the call site, make meta_window_tile() fall back to the current
monitor if nothing set it prior to the call.
This will make it more convenient for test cases to test tiling
behavior.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The test tests that (for both X11 and Wayland) that:
* The client unmaximizes after mapping maximized to a predictable size
* That the client unmaximizes to the same size after toggling maximize
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
This makes sure that a client has properly responded to a configure
event it itself triggered. In practice, this is just two 'wait'
commands, with a 'dispatch' in between, which is needed because a single
one does not reliably include the two way round trip happening when e.g.
responding to a unmaximize configure event triggered by a unmaximize
request.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The 'assert_size' command checks that the size of the window, both
client side and compositor side, corresponds to an expected size set by
the test case.
The size comparison can only be done when the window is using 'csd', in
order for both the client and server to have the same amount of
understanding of the title bar. For ssd, the client cannot know how
large the title bar, thus cannot verify the full window size.
Sizes can be specified to mean the size of the monitor divided by a
number. This is that one can make sure a window is maximized or
fullscreened correctly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
Gtk is quite buggy and "fluid" in how it handles the shadow margins for
windows under X11. The "size" of the window fluctuate between including and
excluding a shadow margin in a way that causes issues, as there are no
atomic update of any state going on.
In order to avoid running into those particular issues now, lets get rid
of shadows so the margins are always zero, when the client is using the
X11 backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
To get some kind of consistency between what 'resize' means for the
compositor and the client, make the size correspond to the "frame rect"
of the window, i.e. the window geometry in the Wayland case, and the
window size including the titlebar in the X11 case.
This is so that the window size later can be reliably compared both in
the compositor and in the client using the same expected dimensions.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
When toying with the test client to try to reproduce issues (e.g.
writing commands on stdin to create and manipulate windows), when you
write a command incorrectly you'll get a warning printed to standard
out. The problem, however, is that it doesn't include a line break in
the end, meaning when you type the correct command, it won't be on a new
line.
Fix this minor annoyance by adding line breaks to all warning messages.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The test client could already understand the resize command, but they
could not be added to metatests as the command was not properly plumbed
via the test runner. Establish the plumbing for the resize command so
that resize tests can be added.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
