The redraw_pending boolean is used to schedule the first stage update
after starting Clutter. This flag is superfluous because we have the
pending_finish_queue_redraws flag which does the same.
While at it, also remove the redraw_count debug variable, since there
should be better ways to count the number of queued redraws nowadays,
for example Sysprof marks.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
Queueing a redraw with a clip is easy enough and this function is
private anyway, so remove it and call _clutter_actor_queue_redraw_full()
instead in the one function using it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
ClutterRedrawFlags are a way to give Clutter additional context
about what it needs to redraw. There currently is only one flag defined,
CLUTTER_REDRAW_CLIPPED_TO_ALLOCATION, this flag would clip the redraw to
the actors current allocation.
Since ClutterActor also provides the clip_to_allocation property (which
affects the paint volume of the actor instead of only one redraw), the
additional CLIPPED_TO_ALLOCATION flag seems unnecessary. It's also only
defined to be used privately in Clutter, which it never is, so let's
remove it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
Turns out the g_signal_has_handler_pending() call in
update_stage_views() is actually more expensive than comparing the
sorted list (which is usually very short), so remove that and simply
always emit the signal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1524
This commit introduces a few important changes in order to
acommodate graphene_ray_t. Most of them are positive changes,
so don't panic :)
The first very visible change is that neither the actor box
nor the clip rectangles are projected before being pushed.
This required changing the parameters of the related functions
at both ClutterPickContext, and ClutterPickStack, to receive
boxes instead of vertices. These rectangles are projected on
demand now, so in the best case (first actor picked) only
one projection happens; and in the worst case, it projects
as much as it does now.
The second important change is that there are no more checks
for axis-alignment anymore. That's because picking now happens
in 3D space, using triangles.
Talking about triangles in 3D space, this is what is used now
for picking. We break down each actor rectangle in 2 triangles,
and check if the projected pick point is inside any one of them,
of if the ray intersects any one of them. The same check happens
for the clip rectangles.
Checking the projected pick point is both an optimization for the
2D case, and a workaround to graphene_ray_t problems with float
precision, which is specially visible on edges such as the top
bar.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1509
ClutterPickStack is a new boxed type that stores the vertices
and clip rectangles. It is meant to be a byproduct of picking,
and takes over most of what ClutterStage currently does.
It introduces a 'seal' system, inspired by MetaKmsUpdate. After
the pick operation is done, and the rectangles are collected,
the pick stack is sealed, and is not allowed to be externally
modified anymore. Internally, it still can invalidate pick
records when an actor is destroyed.
For now, it handles both the clip rectangles, and the matrix
stack, separatedly. Future commits will rearrange this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1509
The "paint" signal of ClutterActor has been a pain for everyone involved
long enough now, turns out we actually use it nowhere except tests
anymore (which has been handled in the last commits), so get rid of it
for good before anyone starts using it again.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1522
This is a bit scattered around, with the setter/getter in Clutter, and
it only being only directly honored in Wayland (it goes straight through
device properties in X11).
Make this private native API, and out of public ClutterInputDevice API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
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
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
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
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/2973https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
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
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
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
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
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
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
_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
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
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
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
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
