Add affine transformation matrix

[Febbe]

This adds a basic affine transformation matrix similar to the cairo_matrix_t, but independent and in the xoj namespace.

• fixed an issue of a missing implementation of the ostream& operator<< overload for Rectangles.

[Febbe]

@bhennion what do you think about that simpler version of an affine transformation? I did not include a scaling parameter for strokes, since this is bound to strokes only. I also think, that the width of a stroke should not be a parameter of the element's virtual scale function.

Should I move all matrix functions into the header file? This might improve performance, but it will increase build time a bit.

[bhennion]

This looks reasonible to me. Of course, the question of speed an efficiency is crucial, so having a benchmark (e.g. as a disabled test unit) wouldn't hurt.

[bhennion]

Should I move all matrix functions into the header file? This might improve performance, but it will increase build time a bit.

Benchmark it and if it gives a significant execution speed gain, then yes!

[Febbe]

Should I move all matrix functions into the header file? This might improve performance, but it will increase build time a bit.

Benchmark it and if it gives a significant execution speed gain, then yes!

Interesting, 10 times faster, using constexpr

PS C:\Users\Febbe\workspace\xournalpp\test\bench\matrix\build> .\Release\bench_matrix.exe
2024-04-05T00:32:46+02:00
Running C:\Users\Febbe\workspace\xournalpp\test\bench\matrix\build\Release\bench_matrix.exe
Run on (12 X 4691 MHz CPU s)
CPU Caches:
  L1 Data 32 KiB (x6)
  L1 Instruction 32 KiB (x6)
  L2 Unified 1024 KiB (x6)
  L3 Unified 32768 KiB (x1)
-----------------------------------------------------
Benchmark           Time             CPU   Iterations
-----------------------------------------------------
v1               9.31 ns         8.37 ns    112000000
v2              0.943 ns        0.753 ns    746666667

[bhennion]

There is one thing that is not so clear to me. You want every Element to store its transformation matrix, correct?
From a drawing perspective, is sounds good, but there are other bits for which things look more complicated: e.g. determining if a Stroke is within a "Region selection" (or even a "Rectangle selection" for that matter, e.g. after a rotation).

Also, for rendering purposes, it matters that we can easily access the bounding box of a Stroke. If a rotation is applied, we can rotate the original bounding box and take the smallest rectangle containing it (so your Matrix::multiply(Rectangle) -> Rectangle), but this is typically way larger than the actual bounding box, thus leading to bigger areas being rerendered.

The same question applies to snapping and the computation of the "snappingBounds".

[Febbe]

There is one thing that is not so clear to me. You want every Element to store its transformation matrix, correct? From a drawing perspective, is sounds good, but there are other bits for which things look more complicated: e.g. determining if a Stroke is within a "Region selection" (or even a "Rectangle selection" for that matter, e.g. after a rotation).

Also, for rendering purposes, it matters that we can easily access the bounding box of a Stroke. If a rotation is applied, we can rotate the original bounding box and take the smallest rectangle containing it (so your Matrix::multiply(Rectangle) -> Rectangle), but this is typically way larger than the actual bounding box, thus leading to bigger areas being rerendered.

The same question applies to snapping and the computation of the "snappingBounds".

I also stumbled over that. And we should discuss this. However, for the other elements, where the inner representation does not change, it is better to use a transformation matrix (Tex, Text, Pictures, PDF).

For strokes, we have the problem, that the line width is messed up, as soon the x and y scaling is distinct. Even it behaves exactly like it should from the drawing perspective. But the user might only want to transform the points, not the linewidth.

Regarding snapping, I would not return a rectangle anymore:
For points, the first and last, maybe center points are more interesting.
For rectangular Shapes like pictures/PDF all the edges might be better to snap to.
Therefore, I would return a SmallVector of Points, rather a Rectangle.

Regarding the bounds to update the drawing, I don't think that the impact is that large, the maximum factor of the resulting Rectangle is exactly 2. Always looping over hundreds of points might be worse.
There is also a way to retrieve the area with the cairo_*_extents function, like cairo_stroke_extents.
I probably should benchmark this.