GitLab

It's been superseded by simpler 2D culling in a1dd3c43, which also
seems to cull more.

GNOME/mutter!1457

All events should be allocated, stack allocation is avoided and should
be avoided in the future, probably by making ClutterEvent structs opaque.

!1475

Peeking doesn't seem such a good idea when we switch to async queues.
Luckily nobody seems to be using this.

!1475

It's nicer to propagate along.

GNOME/mutter!1475

Use a typedef for MetaRemoteDesktop, so tests poking MetaBackend don't
indirectly depend upon generated headers. This is arguably a code fix
for a build system bug.

!1470

Fixes: #1449
(or something...)

They have been replaced with using debug string parsing and topics.

GNOME/mutter!1465

This makes it possible to run e.g.

    env MUTTER_DEBUG=input:geometry gnome-shell

which will enable the 'META_DEBUG_INPUT' and 'META_DEBUG_GEOMETRY'
topics.

GNOME/mutter!1465

GNOME/mutter!1465

GNOME/mutter!1465

It was logged using the 'xinerama' topic during placement calculation,
which doesn't seem very relevant here since a handful of years.

GNOME/mutter!1465

This allows to call the backend finalize function on teardown.

GNOME/mutter!1438

Mutter still relies heavily on singletons such as its MetaBackend.

For that, the backend implementation has a meta_init_backend() function
which is called at startup from meta_init(), which creates the desired
backend and sets the singleton which is returned by meta_get_backend().

Unfortunately, that means that the backend is never actually freed, and
all the code from the backend finalize function never actually get
called.

Add a meta_release_backend() to free the backend singleton.

GNOME/mutter!1438

The input settings constructor installs callback functions on device
added/remove and tool-changed.

However, on dispose, those signals are not disconnected, meaning that on
teardown, once the devices get removed eventually, the callback will
still fire and call the callback with freed data, causing a crash.

Make sure we clear the signals on devices on dispose, to avoid the crash
on teardown.

GNOME/mutter!1438

Adios, amiga.

GNOME/mutter!1439

GNOME/mutter!1439

GNOME/mutter!1439

A boring one, with the exception that row and column needed to be
swapped. For the sake of consistency, the variable names were also
synchronized with the values they hold, so e.g. xy → yx, etc.

GNOME/mutter!1439

This commit encompasses the trivial ones.

!1439

Yet another case of swapping operations order upside down.

!1439

This is a slightly delicate port; much like the ClutterActor port,
using graphene required swapping the order of operations upside down.

GNOME/mutter!1439

These are the easy, trivial ones.

GNOME/mutter!1439

This one is a bit tricky. The tl;dr; is that switching from right-hand
multiplication to left-hand multiplication required applying the stack
from left to root. This actually allowed simplifying the code a bit,
since CoglMatrixEntry only stores a pointer to its parent, and that's
all we need to know for left-hand multiplication.

GNOME/mutter!1439

Instead of heap allocated graphene matrices, embed them into the
entries themselves. That makes the matrix magazine unused, and thus
also remove it.

GNOME/mutter!1439

GNOME/mutter!1439

!1439

!1439

GNOME/mutter!1439

GNOME/mutter!1439

In this case, since we are building the entire matrix by ourselves,
reverse the order of operations (translate + scale → scale + translate)
and build it using graphene-specific APIs.

GNOME/mutter!1439

Switch to using CoglFramebuffer APIs, which use the modelview matrix
stack. CoglMatrixStack will be ported to graphene APIs later, but it
will be transparent to this change.

GNOME/mutter!1439

This is another instance of graphene reversing the order of operations (see
the commit notes of how ClutterActor was ported.) The tl;dr; here is that,
in the CoglMatrix past, we used to do:

  (actor transforms) → scale

and now, it's the other way round:

  scale → (actor transforms)

due to changing from right-handed multiplications (CoglMatrix) to left-handed
ones (graphene_matrix_t).

!1439

ClutterActor is a particularly heavy user of matrices, and
switching to graphene_matrix_* APIs means we had to change
the order of operations due to left-hand vs right-hand
differences.

When applying the actor transform, there are 2 main branches
that can be followed: the default transforms, and when a
custom transform is set.

To facilitate review, here's the table that I've made to
guide myself:

+--------------- Case 1: Default Transforms --------------+
|        CoglMatrix          |      graphene_matrix_t     |
+----------------------------+----------------------------+
| multiply (child transform) | translate (-pivot)         |
| translate (allocation)¹    | rotate_x (angle)           |
| translate (pivot)¹         | rotate_y (angle)           |
| translate (translation)¹   | rotate_z (angle)           |
| scale (sx, sy, sz)         | scale (sx, sy, sz)         |
| rotate_z (angle)           | translate (translation)¹   |
| rotate_y (angle)           | translate (pivot)¹         |
| rotate_x (angle)           | translate (allocation)¹    |
| translate (-pivot)         | multiply (child transform) |
+----------------------------+----------------------------+

¹ - these 3 translations are simplified as a single call
    to translate(allocation + pivot + translation)

+---------------- Case 2: Custom Transform ---------------+
|        CoglMatrix          |      graphene_matrix_t     |
+----------------------------+----------------------------+
| multiply (child transform) | translate (-pivot)         |
| translate (allocation)²    | multiply (transform)       |
| translate (pivot)²         | translate (pivot)²         |
| multiply (transform)       | translate (allocation)²    |
| translate (-pivot)         | multiply (child transform) |
+----------------------------+----------------------------+

² - likewise, these 2 translations are simplified as a
    single call to translate(allocation + pivot)

GNOME/mutter!1439

Switch away from cogl_matrix_* APIs in favor of graphene_matrix_*
ones. Notice that cogl_matrix_get_value() swaps row and column,
which is reflected here.

GNOME/mutter!1439

Move and simplify cogl_matrix_view_2d_in_perspective() to inside
ClutterStage, since it's the only consumer of this API, and remove
it from Cogl.

GNOME/mutter!1439

This special precision-bearing calculation will be used in other
places, so better share them all here.

GNOME/mutter!1439

CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.

!1439

Ideally, we would use Graphene to do that, however as of now Graphene
lacks these APIs so we still need these helpers. Since we're preparing
to get rid of CoglMatrix, move them to a separate file, and rename them
with the 'cogl_graphene' prefix.

Since I'm already touching the world with this change, I'm also renaming
cogl_matrix_transform_point() to cogl_graphene_matrix_project_point(),
as per XXX comment, to make it consistent with the transform/projection
semantics in place.

GNOME/mutter!1439

Given that CoglMatrix is simply a typedef to graphene_matrix_t, we can
remove all the GType machinery and reuse Graphene's.

Also remove the clutter-cogl helper, and cogl_matrix_to_graphene_matrix()
which is now unused.

GNOME/mutter!1439

After the previous commit, the only field in the CoglMatrix structure is
a graphene_matrix_t. That means that CoglMatrix is effectively a graphene
matrix now, and the CoglMatrix struct isn't that much useful anymore.

Remove the CoglMatrix structure and make the CoglMatrix type a typedef to
graphene_matrix_t.

GNOME/mutter!1439

Remove the cached inverse, and dirty flags, and typedef CoglMatrix to
graphene_matrix_t itself. I preverved the type for this commit to help
reducing the commit size, next commits will remove the CoglMatrix type.

GNOME/mutter!1439