Commit Graph

26580 Commits

Author SHA1 Message Date
Carlos Garnacho
1b39b92fa5 xwayland: Protect against MetaX11Display abruptly closing
If the MetaX11Display abruptly closed when X11 windows were present,
we would still try to deal with them while freezing/thawing for the
"fade out" animation.

At the bottom of that, the X server may be gone, just try to cope
with it.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1447
2020-10-21 18:57:12 +02:00
Uday Kiran Pichika
d504086ebf cogl: correcting the cogl trace log
Remove the extra & symbol appearing in cogl debug log

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1517
2020-10-21 12:10:16 +00:00
Uday Kiran Pichika
9d0bac0754 output: Move edid parse function to the right file
Move the edid parsing function from MetaMonitorManager to MetaOutput
to read the monitor manufacturer,serial,vendor,etc.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1516/
2020-10-21 17:04:44 +05:30
Jonas Ådahl
cd52288ddc wayland: Allow specifying Wayland display name from command line
Useful to avoid warnings when starting when there is already an active
Wayland compositor in the session.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1515
2020-10-20 21:16:30 +00:00
Jonas Dreßler
de610a13f1 clutter/actor: Reset allocation when unrealizing actor
Since commit eb9cd3857d we initialize the allocation of ClutterActors to
an UNINITIALIZED ClutterActorBox. We do that to ensure the actor even
emits notify::allocation in case it got a new valid allocation of
0,0,0,0.

Now there's still the case where an actor gets removed from the
scenegraph and added again to a different parent, in this case we still
don't emit notify::allocation right now in case the new allocation
equals the old one. There's two good reasons to do so though:

1) To Clutter, there's no difference between a newly created actor and
an actor which got removed from the scenegraph, it's not consistent to
always notify the allocation property in the former situation, but not
always notify it in the latter situation.

2) When an allocation changes, Clutter notifies the subtree of that
actor about an absolute geometry change (see the call to
transform_changed() in clutter_actor_set_allocation_internal()). Now
when an actor gets reparented, obviously the absolute geometry might
change, so to make sure transform_changed() is always called in that
case we need to make sure an allocation change happens.

So simply reset the allocation property of the actor to an UNINITIALIZED
ClutterActorBox as soon as it gets unrealized.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1498
2020-10-20 18:22:10 +02:00
Jonas Dreßler
76578e5aa0 clutter/actor: Remove absolute_origin_changed flag again
We introduced the absolute_origin_changed flag when preparing for the
removal of ClutterAllocationFlags in commit dc8e5c7f8b. Turns out in the
mean-time commit df4eeff6f2 happened, which renders the whole
absolute_origin_changed flag moot.

That's because we now notify the whole subtree about the absolute origin
change by calling transform_changed() when the allocation of an actor
changes. transform_changed() traverses the subtree and calls
absolute_geometry_changed() on every actor immediately, which renders
the whole propagation of the absolute_origin_changed flag obsolete.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1498
2020-10-20 18:22:10 +02:00
Jonas Dreßler
29caa5bea5 clutter/actor: Don't queue relayouts inside add/remove_child_internal
Since we now moved the queuing of relayouts into the mapping and
unmapping functions, we no longer need to do it when adding or removing
a child, that's because removing a child always unmaps the child, and
adding it to a stage (if it's visible) will map it.

So remove those calls to queue_relayout() since they're no longer
needed.

With the above we no longer queue a relayout in
clutter_actor_add_child_internal(), that means there's one place where
we need to explicitely queue relayouts now: That's when using the
set_child_at_index/above/below() APIs, those are special because they
avoid unmapping and mapping of actors and would now no longer get a
relayout.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
2020-10-20 15:27:43 +00:00
Jonas Dreßler
3bca29f303 clutter/actor: Only allocate when actor is mapped, not only visible
In theory there's no big difference between only handling mapped actors
vs only handling visible actors in clutter_actor_allocate(): The
function is called recursively starting with an actor that is attached
to a stage, so it should only be called on mapped actors anyway.

The behavior of skipping hidden actors was introduced as an optimization
with commit 0eab73dc. Since the last commit, we handle
enable_paint_unmapped a bit better and don't do unnecessary work when
mapping or unmapping, so we can now be a bit stricter enforcing our
invariants and only allow mapped actors in clutter_actor_allocate().

We need to exclude toplevel actors from this check since the stage has a
very different mapped state than normal actors, depending on the
mappedness of the x11 window. Also we need to make an exception for
clones (of course...): Those need their source actor to have an
allocation, which means they might try to force-allocate it, and in that
case we shouldn't bail out of clutter_actor_allocate().

Also moving the clutter_actor_queue_relayout() call from
clutter_actor_real_show() to clutter_actor_real_map() seems to fix a bug
where we don't queue redraws/relayouts on children when a parent gets
shown.

Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2973

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
2020-10-20 15:27:43 +00:00
Jonas Dreßler
717b857bd8 clutter/actor: Use separate priv pointer in clutter_actor_real_(un)map
We're accessing self->priv quite often in those functions, it makes
sense to use a separate variable for it.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
2020-10-20 15:27:43 +00:00
Jonas Dreßler
9b50215008 clutter/actor: Handle getting (un-)mapped during painting differently
We currently support only one case where an actor can get mapped or
unmapped during painting, that is using
_clutter_actor_enable_paint_unmapped() (although we could arguably do a
better job explicitely forbidding it in other cases). This function is
called when painting ClutterClone or MetaWindowActors during
screensharing. It temporarily (fake) realizes and maps the actor and all
its children so it can get painted.

Now a problem will appear when we'll start coupling layout and the
mapped state of actors more closely with the next commit: Since
enable_paint_unmapped() is meant to be enabled and disabled during every
clone paint, we also notify the "mapped" property twice on every clone
paint. That means with the next commit we would queue a relayout for the
source actor on every clone paint.

To avoid this unnecessary work, check whether we're being painted while
unmapped using the new unmapped_paint_branch_counter. Then avoid queuing
relayouts or invalidating paint volumes in that case.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
2020-10-20 15:27:43 +00:00
Jonas Dreßler
650efb6445 tests/conform/actor-pivot-point: Show stage before allocating
We're going to enforce some invariants a bit stricter and will only
allow allocating if an actor is mapped, not only visible.

Since actors are only mapped if their parent is mapped and stages are
hidden by default, we need to show the stage to ensure the actors are
mapped before we allocate them. So do that and call clutter_actor_show()
on the stage before fake-allocating the test actors.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
2020-10-20 15:27:43 +00:00
Jonas Dreßler
cbf3001bc2 clutter/actor: Add private API to get whether we're painting unmapped
Add new private API to ClutterActor, returning TRUE in case the actor is
being painted while unmapped. This is useful for implementations of the
paint() vfunc or for signal handlers of the "notify::mapped" signal.

Use this API in CallyActor to properly detect "notify::mapped" emissions
while painting unmapped, this fixes detecting the case where
painting-unmapped is used for screencasting.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
2020-10-20 15:27:43 +00:00
Jonas Dreßler
bf7cfb877c clutter/actor: Introduce counter for painting in an unmapped branch
Just like the existing in_cloned_branch counter, add a property which
tracks whether the actor is part of a subtree that's being painted while
unmapped. This is going to be useful for a few things, for example
changing the clutter_actor_is_in_clone_paint() API to use
enable_paint_unmapped instead of in_clone_paint.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
2020-10-20 15:27:43 +00:00
Jonas Dreßler
734a7cc16f clutter/actor: Alway call queue_relayout() when showing actors
clutter_actor_queue_relayout() detects whether a parent has the
NO_LAYOUT flag set by itself and then queues a shallow relayout for us.
There's no need to duplicate that logic when showing actors, so simply
call clutter_actor_queue_relayout() and let that handle it.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
2020-10-20 15:27:43 +00:00
Daniel van Vugt
345976192d wayland-buffer: Add debug logging of pixel format in use
Enable it with environment `MUTTER_DEBUG=wayland`.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1387
2020-10-20 09:53:53 +00:00
Daniel van Vugt
e480d0c71e wayland-dma-buf: Add debug logging of pixel format in use
Enable it with environment `MUTTER_DEBUG=wayland`.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1387
2020-10-20 09:53:52 +00:00
Daniel van Vugt
716ecf6cdf util: Add META_DEBUG_WAYLAND debug topic
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1387
2020-10-20 09:53:52 +00:00
Daniel van Vugt
0501d3020e cogl-winsys-egl: Log the color depth in use
Enable it with environment `COGL_DEBUG=winsys`.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1387
2020-10-20 09:53:52 +00:00
Jonas Dreßler
d2f8a30625 clutter/paint-volume: Use graphene for computing union of paint volumes
Apparently clutter_paint_volume_union() has problems building the union
of two paint volumes in eye coordinates, that's probably because of the
negative coordinates that come into play there.

Circumvent that by making even more use of Graphene and letting it take
care of computing the union. We do that by creating two graphene_box_t's
from the axis-aligned paint volumes and intersecting those boxes, then
setting our vertices to the new min and max points of the resulting box.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1507
2020-10-19 21:38:51 +02:00
Olivier Fourdan
7ab3eac0e2 constraints: Use "orig" rectangle for interactive resize
Bug 448183 fixed an issue with _NET_WM_MOVERESIZE_WINDOW not moving a
window by basing the resize on the current (new) rectangle instead of
the original rectangle.

While this fixes the issue with _NET_WM_MOVERESIZE_WINDOW, this also
causes windows with a size increment to move when the resize also
implies a move, such windows might drift while resizing.

Make sure to use the current rectangle for non-interactive resizes only.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/543
2020-10-19 11:16:12 +02:00
Olivier Fourdan
deaa9480a8 window-props: Check for actual size hints changes
The XSizeHints set by X11 clients give a hint to the window manager
about size increment, aspect ratio, base, minimum and maximum size, etc.

When an X11 client changes those values, there is a good chance that it
will affect the actual window size in some way, and mutter rightfully
queue a window resize in that case.

However, mutter does not check if any of the hints have actually changed
and unconditionally queue a window resize whenever a client changes its
WM_NORMAL_HINTS property.

That can be a problem when a zealous client such as xterm decides to
update its WM_NORMAL_HINTS property on resize, because in return mutter
will queue a non-user driven resize in the middle of user-driven events,
hence defeating the purpose of the META_MOVE_RESIZE_USER_ACTION flag.

To avoid that issue, make mutter a bit smarter and avoid queuing a
window resize if the XSizeHints haven't actually changed.

https://gitlab.gnome.org/GNOME/mutter/-/issues/543
2020-10-19 11:16:12 +02:00
Olivier Fourdan
03c69ed8cf window: Do not go past size hints on resize
On interactive resize, mutter calculates the difference in size based on
the pointer location and relies on window constraints to ensure the
minimum size is honored.

Wayland however does asynchronous window configuration, meaning that not
checking for size hints early enough may lead to the window moving as
the locations was initially computed on a size which will be invalidate
by the client eventually.

Make sure to respect the client size hint on update_resize() so that we
don't end up with a window moving unexpectedly when the client
eventually acked the configuration.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1495
2020-10-19 11:16:12 +02:00
Robert Mader
554f7984e9 window/wayland: Offset position with size mismatch when finishing a resize
Analogous to commit 8bdd2aa7db, calculate the size missmatch offset
also when finishing a resize.

Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/396
2020-10-19 11:16:12 +02:00
Hans de Goede
ec18a559c6 monitor-manager: Ignore tablet-mode-switch on initial config of native portrait mode panels
Many tablets have a native portrait mode panel, yet come with a keyboard dock,
where the device gets docked in landscape mode. To avoid the display being
on its side when mutter starts while the tablet is docked, we need to take
the accelerometer reported orientation into account even if there is a
tablet-mode-switch which indicates that the device is NOT in tablet-mode
(because it is docked).

Add special handling for the first time the "orientation-changed"
signal gets signalled by the orientation-manager, which happens after it
has successfully claimed the accelerometer with iio-sensor-proxy.

The added special handling of the initial "orientation-changed" signal
does a number of checks:

1. panel_orientation_managed is false because of the tablet-mode-switch and not
   because of other reasons.

2. The device has a native portrait mode panel (and thus likely needs rotation
   to display the image the right way up when docked).

If all these checks succeed then it continues with creating a new
monitors-config based on the orientation ignoring the panel_orientation_managed
value (for the initial/first "orientation-changed" signal only).

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-18 21:35:10 +00:00
Hans de Goede
1b13f50582 monitor-manager: Update orientation based config when panel_orientation_managed changes
The orientation reported by the orientation_manager may have changed while
panel_orientation_managed was false. So when panel_orientation_managed
changes to true we should re-check the orientation.

This fixes the orientation not being correct when e.g. taking a 360 degree
hinges 2-in-1 in clamshell mode (so landscape orientation) and then folding
it into tablet mode while holding it in portrait orientation.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-18 21:35:09 +00:00
Hans de Goede
4c12208363 monitor-manager: Add a handle_orientation_change helper function
Move the bulk of orientation_changed to a new handle_orientation_change
helper function. This is a preparation patch for further orientation
handling related changes.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-18 21:35:09 +00:00
Hans de Goede
21c714a0f2 seat-native: Add support for tablet-mode-switch being hot-unplugged
Add support for the (mostly theoretical) case of an input-device
offering tablet-mode-switch functionality being unplugged.

This makes the has_tablet_switch handling identical to the has_touchscreen
handling, leading to more consistent code.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-18 21:35:09 +00:00
Hans de Goede
88cabf8039 seat-native: Check for tablet-switch devices from meta_seat_native_constructed
Detect if a tablet-mode-switch device is already present when mutter
starts by checking for this from meta_seat_native_constructed. This
mirrors how we also set has_touchscreen from meta_seat_native_constructed.

This fixes tablet-mode-switches only being recognized when they are added
at runtime.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-18 21:35:09 +00:00
Hans de Goede
6c240dc83b seat-native: Fix has_touchscreen becoming FALSE when a non touchscreen device gets added
Unconditionally setting has_touchscreen to check_touch_mode
when a new device gets added leads to has_touchscreen becoming
false when during runtime e.g. an USB keyboard gets plugged in.

Fix this by setting has_touchscreen to TRUE when check_touch_mode
is TRUE and leaving it alone otherwise.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-18 21:35:09 +00:00
Hans de Goede
b5d21f00f8 backend: Use new clutter_seat_has_touchscreen helper
Replace the meta-backend.c private check_has_physical_touchscreen
function with a call to the new clutter_seat_has_touchscreen helper.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-18 21:35:08 +00:00
Hans de Goede
3b181c6754 clutter: Add ClutterSeat::clutter_seat_has_touchscreen() helper function
Add a helper function to determine if a seat has a (physical)
touchscreen associated with it.

Currently src/backends/meta-backend.c has a private version of this
(check_has_physical_touchscreen) and further patches in this patch-set
need the same functionality. So add a generic helper for this to
avoid code duplication.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
2020-10-18 21:35:08 +00:00
Robert Mader
b2f2050b95 renderer-native: Fix GObjectify oversight
This was forgotten in eb14da3874, triggering crashes.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1510
2020-10-18 11:25:27 +02:00
Georges Basile Stavracas Neto
bc41a88c92 clutter/stage: Replace _cogl_util_get_eye_planes_for_screen_poly()
_cogl_util_get_eye_planes_for_screen_poly() is quite a complicated beast. Ever
since Clutter became a compositor toolkit, and specially after we switched to
graphene_frustum_t on paint volumes, we can brutally simplify this function.

The new code assumes camera is at (0, 0, 0) at world coordinates (i.e. before
applying the projection). We also consider that the redraw clip are at stage
coordinates. That means that converting the clip rectangle to world rectangle
is simply a matter of projecting the corresponding vertices using the "view"
matrix. Furthermore, we only need to project the top-left, and bottom-right
vertices, since top-right and bottom-left can be derived from those two.

The frustum setup still uses triplets of vertices to setup the planes, except
now the first vertex is always the camera (hardcoded to 0, 0, 0), and the other
two vertices are the projected clip rectangle vertices.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:46:26 -03:00
Georges Basile Stavracas Neto
f7d0461768 clutter/stage: Simplify frustum setup function
We guarantee to never pass NULL clips anymore, so there's no need
to check for such case.

Remove the check for NULL clip, and remove all related variables.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:46:26 -03:00
Georges Basile Stavracas Neto
2ca20783e5 clutter/actor: Remove region culling
We can trust the clip frusta array to encode this information now.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:46:26 -03:00
Georges Basile Stavracas Neto
d1d3ac6b20 clutter/stage: Use multiple frusta depending on the redraw clip
The redraw clip region may contain multiple clip rectangles. We currently
only use the extents of this region, but having multiple frusta for each
rectangle is a better alternative, and will allow us to remove the extra
projection we currently do.

Make the clip frustum an array, with multiple frusta.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:46:23 -03:00
Georges Basile Stavracas Neto
63d05565f6 clutter/stage: Move pick cache invalidation out of setup
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
cf9d06164d clutter/stage: Remove outdated comment
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
feb8397c97 clutter/stage: Move clip frustum to ClutterPaintContext
The clip planes / frustum are contextual to painting. In the past, for
the lack of a better place, it was added to ClutterStage, but now we
have an appropriate home for such data: ClutterPaintContext.

Move the frustum to the paint context.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
b6fa26cf45 clutter/stage: Don't setup view on pick
While refactoring the clipping planes / frustum code, it became more and
more evident that we do not need to update them while picking. Picking
nowadays goes through a completely different code path, that does not
rely on paint volume culling.

While it might be interesting to eventually also cull out based on paint
volumes, it certainly won't go through the painting code anymore.

Remove setting up the view when picking, and rename functions appropriatedly.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
496aea51af clutter: Remove CLUTTER_CULL_RESULT_PARTIAL
Culling paint volumes don't give this level of detail anymore, and in
fact knowing whether it was partially or fully in was only being used
in a debug path. For the purposes of culling, it doesn't matter if a
given actor is partially or completely inside the frustum; either way,
it must be painted.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
80bd44cba0 clutter/actor: Use switch instead of if/else
To improve legibility of the code.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
a84dccfd64 clutter/stage: Use graphene_frustum_t for clipping
Instead of 4 planes, use a graphene_frustum_t to store the clipping
planes.

The cautious reviewer might noticed that we are now setting up 6
planes: the 4 planes we were doing before, plus 2 extra planes in
the Z axis. These extra planes simulate an "infinite" Z far, and
an "on-camera" Z near.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
338a9275b4 clutter: Remove ClutterPlane
It is unused now.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
964229acf4 clutter/actor: Trivial code shuffling
Retrieving the stage from the actor is almost free, but this is a
hot path anyway and we can bail out before that.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
01ccc54ce8 clutter/actor: Remove unnecessary check
The stage clip is *never* NULL - it is a structure field of ClutterStage
itself.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
793ca68d8c clutter/stage: Use graphene_plane_t for clipping planes
It allows us to remove quite a bunch of code, and not deal with part
of the mind-melting maths behind it.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
175851eef7 clutter/stage: Simplify view setup
ClutterStage defines the 8 vertices of a frustum:

  4 ----------------------------- 5
  | \                           / |
  |  \                         /  |
  |   0 --------------------- 1   |
  |   |                       |   |
  |   |                       |   |
  |   3 --------------------- 2   |
  |  /                         \  |
  | /                           \ |
  7 ----------------------------- 6

Then, it uses triplets of vertices to create each  clipping plane.
It only sets up 4 planes (it doesn't clip based on depth), defined
by the following vertices:

 * 0 - 4 - 5
 * 1 - 5 - 6
 * 2 - 6 - 7
 * 0 - 7 - 4

The first 3 triplets are selected using the for-loop. However, the
last triplet is different, and is done out of the loop. It could
have been made simpler by using the "3 - 7 - 4" triplet.

Simplify the current code by using the suggested triplet, calculated
inside the for-loop.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
1f99395d20 clutter: Use graphene_matrix_inverse()
Instead of our own implementation that upscales, then downscales back,
use graphene_matrix_inverse() directly. This is possible after switching
to a z-near value that doesn't have problems with float precision.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00
Georges Basile Stavracas Neto
78c648f947 cluter/stage: Use 1.0 for z-near
It doesn't actually matter, since we don't really have cases where we
cross this value, but it's enough to prevent catastrophic cancellation
due to very small float numbers.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
2020-10-16 13:37:44 -03:00