Thank you. But why not use bilinear interpolation to the color approximation. I understand that, when the source axis is (x.a, y.b), x and y are integers, a and b are fractions. the pixels of (x, y), (x + 1, y), (x, y+1) and (x + 1, y + 1) are used to calculate the approximation with weights .Why (x - 1,y) and (x, y - 1 ) are selected as neighbor point when the axis is (x.0, y.0)?

For simplicity let’s say a pixel has 3 parts (using the notion from for your comment):

left (.a =0)

center (.a = 128)

right (.a = 255)

If the rotation gives "use the source pixel’s a = 128" it means the center of the pixel should be written to the destination position. It’s a clear case, no interpolation is required because if the center need to used the neighbor pixels won’t affect it.

If the rotation gives "use source the pixel’s a = 0" it means the very left point of the pixel should be written to the destination position. However, the very left is almost the other pixel on the left. So mix them with equal weight.

Actually, I’ve just figured it on my own however I’m sure others also already used something like this.

I was thinking like:

Some kind of interpolation is required to get smoother edges and lines

If a short vertical line (1x3 px) is rotated only a little bit (1 deg) then it might be no rotation at all because always the same pixel will be sampled.

But it just a rounding error. In reality e,g. the (0;1) pixel should be at (0;1,1).

How to represent it? Oh, the neighbor pixel should matter.

But to what extent? What if exactly the intersection of two pixels or the center of the pixel should be used.

Aha! It should be related to the theoretical distance from the center of the pixel.

If we used float numbers it should be easy to see how far we are from the center be seeing the fraction parts.

But we don’t use floats in LittelvGL. So upscaling should be used to get more precision.