When doing affine transforms on 2D and 3D spaces, operations are
done relative to the origin. That means that, when applying
rotations and scales, we must:
* translate (-anchor_x, -anchor_y, -anchor_z)
* apply the operation
* translate (anchor_x, anchor_y, anchor_z)
Since OpenGL has its matrices applied in the reverse order, the
usual way to do it is, then:
* translate (anchor_x, anchor_y, anchor_z)
* apply the operation
* translate (-anchor_x, anchor_y, anchor_z)
However, graphene matrices do not follow the GL format, so matrix
operations are done as the first example. Now that we are using
graphene_matrix_t for every matrix operation, the transform order
is wrong.
Apply the transform operations in the opposite order.
This is an extremely straightforward and minimalistic port of
CoglVector APIs to the corresponding Graphene APIs.
Make ClutterPlane use graphene_vec3_t internally too, for the
simplest purpose of keeping the patch focused.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Mutter requires Clutter, which requires Cogl. That means
Clutter requires all Cogl dependencies, and Mutter requires
all Clutter dependencies as well.
However, currently, Clutter does not pull in its dependencies,
which means we need to link against Cogl manually.
Add Clutter dependencies to declare_dependency() so that the
graphene dependency only needs to be declared once, for Cogl,
and pulled together.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Graphene uses C99 and includes stdbool.h, which adds a
new 'bool' type. Clutter has an a11y test that names a
variable as 'bool' too, and they do not play well together.
Rename this variable to boolean.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
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
Fog is explicitly deprecated in favour of CoglSnippet API,
and in nowhere we are using this deprecated feature, which
means we can simply drop it without any sort of replacement.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/458
Meson 0.50.0 made passing an absolute path to install_headers()'
subdir keyword a fatal error. This means we have to track both
relative (to includedir) paths for header subdirs and absolute
paths for generated headers now :-(
https://gitlab.gnome.org/GNOME/mutter/merge_requests/492
The ClutterVirtualInputDevice API was fixed to use Clutter button
internal codes, whereas the mousekeys still uses evdev codes.
Change the mousekeys implementation to use the Clutter button code
instead to remain compatible with the ClutterVirtualInputDevice API.
Fixes: 24aef44b (Translate from button internal codes to evdev)
https://gitlab.gnome.org/GNOME/mutter/merge_requests/473
Since e3e933c4 a keyval can be temporarily remapped to an unused keycode. Due to
some limitations in XTestFakeKeyEvent, the remapping has to be done in the first
xkb group/layout. In case there are two or more keyboard layouts enabled and the
selected keyboard layout is not the first, clutter_keymap_x11_keycode_for_keyval
will fail to retrieve the correct keycode for a remapped keyval. Let's use the
reserved_keycodes map in order to retrieve the correct keycode if needed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/443
The clamped rectangle currently could not fully contain the original fractional
rectangle because it doesn't take care of the fact that the new width should
consider the fact that flooring we'd translate the rectangle, and thus to cover
the same area we need to take care of it.
So, to properly compute the width and height, calculate x2 and y2 first and then
use this ceiled value to compute the actual width using the floored x1 and y1.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
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
