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
This basically reverts commit 54735dec, which tried to avoid the
GLib-defined types in favor the standard C ones. One exception to this
is the bool type, for which the commit introduces a new type CoglBool.
Let's just get rid of this type in favor of having consistency with the
GLib types. Note by the way that neither CoglBool nor gboolean (which
has a size of `int`) are completely compatible with bool (size `char`).
https://gitlab.gnome.org/GNOME/mutter/merge_requests/321
Unfortunately, many parts of GNOME Shell and Mutter and Clutter
still use the implicit Cogl1 API. As such, it as a transition
between the old and new APIs, it is important to keep the
implicit draw framebuffer updated.
ClutterRootNode does not keep it updated though, and it might
lead to problems when rendering offscreen textures.
Fix that by pushing and popping the root node framebuffer on
pre- and post-draw, respectively.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
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
When painting to an offscreen framebuffer, MetaShapedTexture will
need to have full control of the painting routines of paint nodes.
As such, expose clutter_paint_node_paint() to allow forcing a
paint nodes paint from MetaShapedTexture.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
The multitexture API is not a shortcut for multiple calls
to the single texture API. It is meant to wrap calls to
cogl_framebuffer_draw_multitexture_rectangle(), which
uses the passed texture coordinates at different layers of
the pipeline.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
ClutterImage is a ClutterContent implementation that
has an internally managed CoglTexture. This texture
is recreated when new image data is set.
ClutterContent implementations may have control over
the allocation of the widgets they're attached to,
through CLUTTER_REQUEST_CONTENT_SIZE. On those cases,
if the new image data differs in size from the previous
data, it is important to notify those actors about the
size change. However, currently ClutterImage does not
notify them.
With the introduction of clutter_content_invalidate_size(),
it is possible to report the size changes to attached
actors.
Adapt ClutterImage to invalidate_size() when image data
has different sizes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
ClutterContent has the ability to dictate the layout of any
given actor, through the CLUTTER_REQUEST_CONTENT_SIZE request
mode.
However, there is no way for ClutterContent implementations
to notify their attached actors that the content size changed.
Add a new optional ClutterContent.invalidate_size() vfunc and
clutter_content_invalidate_size().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/405
When profiling gnome-shell it was found that one of the main triggers
of `clutter_actor_queue_relayout` during animations was
`clutter_actor_set_margin_internal` continuously setting the same
zero margins. That's obviously pointless and also expensive. So just
avoid redundant margin changes.
This helps to further improve performance in:
https://gitlab.gnome.org/GNOME/mutter/issues/233,
https://gitlab.gnome.org/GNOME/gnome-shell/issues/349
This change previously landed as 59acb3895 and then got reverted because
it was found to make gnome-shell#517 worse. However that bug now has a
proper fix and this branch isn't really directly related so is being
reproposed...
Just move the minimal bits to this ClutterKeymapEvdev object. Much
of the functionality of a keymap is spread along ClutterSeatEvdev,
ClutterDeviceManagerEvdev and ClutterVirtualInputDevice. Future
refactors are due here.
Also, ideally keymaps are per-seat objects (at least keyboard state
is). We don't expose much info about seats altogether outside the
evdev device manager implementation. We just poke the main seat at
places, but eventually seats should be public.
We thus far have similar objects/code internal to backends. Expose the
minimum API necessary to cater for gnome-shell as a generic object.
So far only the X11 backend has an actual GObject for it, and was made
to be a subclass right away.
`distribute_natural_allocation` expects an input >= 0 of type `gint`. In
`get_preferred_size_for_opposite_orientation` it is used with an unchecked
variable `size` of type `gfloat`, which in case it is `Infinity`, gets
passed on in the macro `MAX (0, size)`. `Infinity` becomes `G_MININT`
when implicitly casted to `gint` in `distribute_natural_allocation`,
triggering the assertion `extra_space >= 0`.
The resulting warning in the log is counter intuitive and not very
helpful.
Use `float` in `distribute_natural_allocation` instead of `gint` and
assert on denormal values so we can more easily identify bugs.
Additionally change some types while at it and add a even more
expressive warning referencing the actor at one point.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/375
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
