Draft: Transformable elements proposal

[Febbe]

This PR tends to implement one of the most desired enhancements (#918), to rotate Images, Text and Latex.
For this, I replaced every explicit position, scale and rotation state in the Elements with affine transformations.
They are never applied to the data, instead the affine transformation is handled to cairo, which itself applies an affine transformation anyway.
This has the advantage,

• that we get rotation support out of the box via cairo and
• that we can reduce computing power, since only one transformation is applied to each Shape
• when cairo drawing uses hardware acceleration, strokes now also will use hardware acceleration for the transformation

Currently, this is not ready to merge, since several code changes added bugs, which are not fixed yet.
But testers and interested people can test it out and give feedback.
Also, it's not possible, to store the transformations.

fixes #918
fixes #2040
fixes #3622
fixes #4899

It will require changes to #3931 and will simplify the implementation.
Only a mirror matrix must be applied to the selection with a pivot point/dimension.
E.g. Matrix(pivot) * mirrorMatrix * Matrix(-pivot)

[Febbe]

@xournalpp/core we need to discuss what we want to do with the file format.
My proposal is, to

• advance the version of it and
• to add the ability, to export to an older version.
• old versions should still be loadable.

But this will be again a lot of work.

[rolandlo]

@xournalpp/core we need to discuss what we want to do with the file format. My proposal is, to

* advance the version of it and

* to add the ability, to export to an older version.

* old versions should still be loadable.

But this will be again a lot of work.

That sounds reasonable. How would you export a rotated images/text/TeXImages though to an older version?

[rolandlo]

• when cairo drawing uses hardware acceleration,

Does it though? I do not think so. For hardware acceleration one has to use the Snapshot/Render Nodes approach in Gtk 4. I have created an example of that in Workbench (the Snapshot demo).

[Febbe]

@xournalpp/core we need to discuss what we want to do with the file format. My proposal is, to

* advance the version of it and

* to add the ability, to export to an older version.

* old versions should still be loadable.

But this will be again a lot of work.

That sounds reasonable. How would you export a rotated images/text/TeXImages though to an older version?

My idea is, to render the rotated PDFs onto a PDF surface and put it as binary data into the xournalpp file.

[Febbe]

• when cairo drawing uses hardware acceleration,

Does it though? I do not think so. For hardware acceleration one has to use the Snapshot/Render Nodes approach in Gtk 4. I have created an example of that in Workbench (the Snapshot demo).

I am totally not sure. I've read something about, that this is implementation defined. Could be, that it only works on Linux with OpenGL or that I misinterpreted the section I've read.

But nevertheless this approach is also somewhat we definitely should do, when we want to switch to render nodes.
It also only applies one matrix transformation per rendering, instead of the extra transformations done for selections.

It can also simplify, the selection handling in general, since the selection just has to apply its transformation.

[rolandlo]

I am totally not sure. I've read something about, that this is implementation defined. Could be, that it only works on Linux with OpenGL or that I misinterpreted the section I've read.

The OpenGL support was removed and has basically unmaintained for a long time before. See e.g. https://news.ycombinator.com/item?id=39442886

I just wanted to argue about this fact about Cairo hardware acceleration, not about the general approach (which makes sense). Yes, in the Snapshot/RenderNodes world using a Gsk.TransformNode or gtk_snapshot_transform_matrix is much simpler than doing extra calculation.

One thing that looked troublesome to me with the transformation matrix approach is scaling strokes, since the stroke segments get distorted when the transformation is not a similarity. This makes a difference when scaling just in one direction. How do you plan to deal with that?

[Febbe]

One thing that looked troublesome to me with the transformation matrix approach is scaling strokes, since the stroke segments get distorted when the transformation is not a similarity. This makes a difference when scaling just in one direction. How do you plan to deal with that?

Right, I have this on my list. @bhennion has the approach, to add an extra parameter in his transformation matrix (don't have his branch on the hand right now).
But I would like to split the stroke size from the basic transformation.

My approach for strokes would be, to also add a transformation matrix for the stroke size, and to scale it like:

| TM * (z,z) |