Rendering off stage we never cull, and previously this was checked by
comparing the "active framebuffer" of the stage, to the current
framebuffer in the cogl stack. Replace this by checking whether the
current paint context is currently drawing on stage or not.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
Just as with painting, add a pick context that carries pick related
temporary state when doing actor picking. It is currently unused, and
will at least at first still carry around a framebuffer to deal track
view transforms etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
When painting, actors rely on semi global state tracked by the state to
get various things needed for painting, such as the current draw
framebuffer. Having state hidden in such ways can be very deceiving as
it's hard to follow changes spread out, and adding more and more state
that should be tracked during a paint gets annoying as they will not
change in isolation but one by one in their own places. To do this
better, introduce a paint context that is passed along in paint calls
that contains the necessary state needed during painting.
The paint context implements a framebuffer stack just as Cogl works,
which is currently needed for offscreen rendering used by clutter.
The same context is passed around for paint nodes, contents and effects
as well.
In this commit, the context is only introduced, but not used. It aims to
replace the Cogl framebuffer stack, and will allow actors to know what
view it is currently painted on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/935
This is inspired by 98892391d764d1cf where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
Clutter has a draw debug mode that allows for painting
paint volumes. Right now, this debug mode uses the old
immediate paint mode.
Switch the painting of paint volumes to use paint nodes,
and sneak a few minor style cleanups.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/890
Now that we unconditionally use ClutterActorNode to
paint ClutterActors, move the PAINT private flag to
the ClutterActorNode. This way, we can run the paint
on the actor anywhere inside the paint tree.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/890
When setting the root node as child of a clip or transform node, we add a
new reference to it, without removing the one that we've previously added
when getting it from the actor node (and that won't ever be unset by the
auto-pointer since the root_node is re-associated).
So, once we add the root node as child and re-define it, unref it.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/908
A compositor is notably opaque (usually has nothing to be painted on!).
gnome-shell sets this hint, but there's no reason why we wouldn't want
it by default.
Also, the color buffer being cleared messes with stencil clips, as the
clear operation by definition ignores the stencil buffer. We want to
use these more extensively in the future, so just drop this API.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/911
Make ClutterActor paint using ClutterTransformNode, ClutterClip
node, and ClutterActorNode. Essencially, the actor node is a
replacement for clutter_actor_continue_paint().
An interesting aspect of this commit is that the order of the
operations is reversed to be preserved.
Before being able to remove the dummy node hack, we'll need to
make ClutterEffects compatible with paint nodes first -- and
naturally, that's enough content for its own merge request.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/872
This is a deprecated property that is not used anywhere
in the codebase. Not by GNOME Shell. Because it uses the
deprecated ClutterGeometry type, it's a good target for
cleaning up, given that ClutterGeometry will be dropped
later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
When clutter actors with key focus are destroyed we emit ::key-focus-out on
them just after their destruction. This is against our assumption that no
signal should be emitted after "::destroy" (see GNOME/mutter!769 [1]), and
in fact could cause the shell to do actions that we won't ever stop on
destroy callback.
To avoid this to happen, use a private function to set its key-state (so we
can avoid looking for the stage) and emit ::key-focus-in/out events and use
this value in both clutter_actor_has_key_focus(),
clutter_actor_grab_key_focus() and on unmap and destruction to unset the
stage key focus before we emit the ::destroy signal.
As result of this, we can now avoid to unset the key focus on actor
destruction in the stage.
[1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/issues/1704
Clutter had support for internal children in its early revisions, but they
were deprecated for long time (commit f41061b8df, more than 7 years ago) and
no one is using them in both clutter and in gnome-shell.
So remove any alternative code path that uses internal children.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/816
ClutterActor took a reference in its transition 'stopped' handler,
aiming to keep the transition alive during signal emission even if it
was removed during. This is, however, already taken care of by
ClutterTimeline, by always taking a reference during its 'stopped'
signal emission, so no need to add another one.
This also has the bonus of making reference ownership simpler, as well
as avoidance of double free if an actor was destroyed before a
transition has finished.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
Implicit transitions had a referenced taken while emitting the
completion signals, but said reference would only be released if it was
had remove-on-complete set to TRUE.
Change this to instead remove the 'is_implicit' state and mark all
implicit transitions as remove-on-complete. This fixes a
ClutterPropertyTransition leak in gnome-shell triggered by e.g. showing
/ hiding menus.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1740https://gitlab.gnome.org/GNOME/mutter/merge_requests/828
Clutter actors might emit property changes in dispose, while unparenting.
However we assume that the ::destroy signal is the last one we emit for an
actor, and that starting from this moment the object is not valid anymore,
and so we don't expect any signal emission from it.
To avoid this, freeze the object notifications on an actor during its
disposition, just before the ::destroy signal emission.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Clutter actors unset their parent on dispose, after emitting the ::destroy
signal, however this could cause ::parent-set signal emission. Since we
assume that after the destruction has been completed the actor isn't valid
anymore, and that during the destroy phase we do all the signal / source
disconnections, this might create unwanted behaviors, as in the signal
callbacks we always assume that the actor isn't in disposed yet.
To avoid this, don't emit ::parent-set signal if the actor is being
destroyed.
Update the actor-destroy test to verify this behavior.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/769
Delayed clutter timelines might be removed while they are still in the
process of being executed, but if they are not playing yet their delay
timeout won't be stopped, causing them to be executed anyway, leading to a
potential crash.
In fact if something else keeps a reference on the timelines (i.e. gjs), the
dispose vfunc delay cancellation won't take effect, causing the timelines to
be started and added to the master clock.
To avoid this, expose clutter_timeline_cancel_delay() function and call it
if a timeline is not playing but has a delay set.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/815https://gitlab.gnome.org/GNOME/mutter/merge_requests/805
`_clutter_actor_get_transition` is almost identical to
`clutter_actor_get_transition` and isn't used anywhere in the code (we
stopped using it with ee00e37b), remove it!
https://gitlab.gnome.org/GNOME/mutter/merge_requests/791
Currently, Clutter does picking by drawing with Cogl and reading
the pixel that's beneath the given point. Since Cogl has a journal
that records drawing operations, and has optimizations to read a
single pixel from a list of rectangle, it would be expected that
we would hit this fast path and not flush the journal while picking.
However, that's not the case: dithering, clipping with scissors, etc,
can all flush the journal, issuing commands to the GPU and making
picking slow. On NVidia-based systems, this glReadPixels() call is
extremely costly.
Introduce geometric picking, and avoid using the Cogl journal entirely.
Do this by introducing a stack of actors in ClutterStage. This stack
is cached, but for now, don't use the cache as much as possible.
The picking routines are still tied to painting.
When projecting the actor vertexes, do it manually and take the modelview
matrix of the framebuffer into account as well.
CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
| | Intel | Nvidia |
| ------: | --------: | -----: |
| Moving the mouse: |
| Before | 10% | 10% |
| After | 6% | 6% |
| Moving a window: |
| Before | 23% | 81% |
| After | 19% | 40% |
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/154,
https://gitlab.gnome.org/GNOME/mutter/issues/691
Helps significantly with: https://gitlab.gnome.org/GNOME/mutter/issues/283,
https://gitlab.gnome.org/GNOME/mutter/issues/590,
https://gitlab.gnome.org/GNOME/mutter/issues/700
v2: Fix code style issues
Simplify quadrilateral checks
Remove the 0.5f hack
Differentiate axis-aligned rectangles
https://gitlab.gnome.org/GNOME/mutter/merge_requests/189
If possible, GLib will try to use the va_marshaller to pass the signal
arguments, rather than unboxing into and out of a `GValue`. This is much
more performant and especially good for often-thrown signals.
The original bug even mentions Clutter performance issues as a drive to
implement the va_marshaller in GLib (see
https://bugzilla.gnome.org/show_bug.cgi?id=661140).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
Some of the marshallers we generate in `clutter-marshal.list` are also
available in GLib, so we don't need to generate them ourselves. Even
more, by passing NULL to `g_signal_new` in these cases will actually
internally optimize this even more by also setting the valist
marshaller, which is a little bit faster than the regular marshalling
using `GValue` and libffi.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/700
Currently nothing in the clutter machinery prevents hidden portions
of the actor tree from calling queue_relayout() (and having it fully
honored).
But that allocation should not be necessary till the actor is shown,
and one of the things we do on show() is queueing a relayout/redraw
after flagging the actor as visible.
We can simply defer clutter_actor_allocate() calls till that show()
call, and leave the needs_allocate and other flags set so we ensure
the allocation is properly set then.
This should cut down some needless operations when invisible portions
of the actor tree change indirectly due to user interaction, or due
to background activity.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/677
Clutter does the nicety of connecting just created PangoContexts to
ClutterBackend signals in order to update it on resolution/font changes.
However the way the signals are disconnected (automatically via
g_signal_connect_object() auto-disconnect feature) may incur into
performance issues with a high enough number of ClutterActors with a
PangoContext (eg. ClutterText) as the lookup by closure is linear across
all signals and handlers.
Keep the handler IDs around, and disconnect them specifically on dispose
so it is more O(1)-ish.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/556
In a multi-monitor setup there is a separate paint run for each monitor.
If an actor doesn't intersect the first monitor painted then it is culled
out for that monitor to save time. Unfortunately this would mean
`clutter_actor_paint` was setting `is_dirty = FALSE` before the actor had
yet been painted on any monitor.
This meant that effects like `ClutterOffscreenEffect` were not receiving
the flag `CLUTTER_EFFECT_PAINT_ACTOR_DIRTY` when they should have, and
so would rightfully think they don't need to do a full internal
invalidation. So `ClutterOffscreenEffect`, and probably other effects,
did not repaint correctly unless on the first monitor in the list.
The fix is to simply avoid setting `is_dirty = FALSE` on those paint
runs where the actor has been culled out (`clutter_actor_continue_paint`
wasn't called). It is only safe to clear the flag after
`clutter_actor_continue_paint` has been called at least once per stage
paint.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1049https://gitlab.gnome.org/GNOME/mutter/merge_requests/511
A clutter actor might be painted on a stage view with a view scale
other than 1. In this case, to show the content in full resolution, the
actor must use a higher resolution resource (e.g. texture), which will
be down scaled to the stage coordinate space, then scaled up again to
the stage view framebuffer scale.
Use a 'resource-scale' property to save information and notify when it
changes.
The resource scale is the ceiled value of the highest stage view scale a
actor is visible on. The value is ceiled because using a higher
resolution resource consistently results in better output quality. One
reason for this is that rendering is often not perfectly pixel aligned,
meaning even if we load a resource with a suitable size, due to us still
scaling ever so slightly, the quality is affected. Using a higher
resolution resource avoids this problem.
For situations inside clutter where the actual maximum view scale is
needed, a function _clutter_actor_get_real_resource_scale() is provided,
which returns the non-ceiled value.
Make sure we ignore resource scale computation requests during size
requests or allocation while ensure we've proper resource-scale on
pre-paint.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
This is an ABI break, hopefully an unimportant one since this signal/vmethod
is barely overridden.
The signal has been added an extra ClutterPaintVolume argument, and has been
given a boolean return value. The recursion to the parents has been taken
out of the default implementation and into the caller, using the returned
boolean parameter to control further propagation.
Passing the ClutterPaintVolume is easier on performance, as we don't need
setting this pointer as gobject data just to retrieve/unset it further
in propagation.
https://bugzilla.gnome.org/show_bug.cgi?id=782344
The ClutterRootNode paint node is theoretically the
top-most node of a paint nodes tree, except that we
are not in the point of having full rendering trees
in Clutter (all rendering performed by paint nodes
is still local and immediate).
When controlling the rendering tree, MetaShapedTexture
may need to paint into an offscreen framebuffer under
some circumstations.
Expose ClutterRootNode so that MetaShapedTexture can
use it to render to offscreen framebuffers.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
