When we try to update the FB, we might face the case in which the effect target
framebuffer does not need any redraw, because it's already properly sized and
scaled, but the filter applied to the pipeline is not, because it has been
computed for a non-fractional scaling.
This is happens for example to clutter actors with a flattening effect (i.e.
override redirect mode set), that might have been generated properly for a
celied scaling level, but when we go fractional we need to ensure to use a
linear filter, as the 1:1 texel:pixel assumption is not true anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
At this level we use ceiled resource-scale when painting fractional value
When using fractional scaling we still need to create an integer-sized
texture and then we should paint it using a size which is proportional
to the real actor size ratio, and only paint a subsample of it, but this
doesn't seem to work properly with some weird scaling values.
Then, it's just better to draw the texture ceiled and then we scale it
down to match the proper actor scaling at paint level.
https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
When resource scale is set we need to generate a scaled PangoLayout (by adding
a new scale attribute, or adjusting the one we already have according the
resource scale), then it has to be painted with proper scaling matrix.
So everything that has to do with PangoLayout has to be in real coordinates,
then clutter logical coords multiplied by resource scaling.
While the actual size of the layout is the one of the PangoLayout divided by
resource scale.
We map the text positions to logical coords by default, while using
the pixel coordinates when painting.
We fall back to scale 1 when calculating preferred size if no scale is
known. The pango layout will not have set a layout scale attribute,
meaning it'll be 1, thus we should just assume the layout scale is 1 here.
Not doing so might result in the preferred size being 0x0 meaning the
actor won't be laid out properly.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/135https://bugzilla.gnome.org/show_bug.cgi?id=765011https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
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
