Optimized matrix calculations for improved performance

[hanion]

Describe the issue (if no issue has been made)

The matrix calculations are slow because we keep making new matrices for moving, rotating, and resizing things. This leads to slow program performance, particularly when we need to perform many of these calculations.

// current
glm::mat4 transform = glm::translate(glm::mat4(1.0f), position)
    * glm::rotate(glm::mat4(1.0f), glm::radians(rotation), {0.0f, 0.0f, 1.0f})
    * glm::scale(glm::mat4(1.0f), {size.x, size.y, 1.0f});

PR impact (Make sure to add closing keywords)

This pull request makes things faster by changing how we handle these calculations, so the program runs much quicker now.

Impact	Issue/PR
Issues this solves	None
Other PRs this solves	None

Proposed fix (Make sure you've read on how to contribute to Hazel)

// change
glm::mat4 transform = glm::mat4(1.0f);
transform = glm::translate(transform, position);
transform = glm::rotate(transform, glm::radians(rotation), { 0.0f, 0.0f, 1.0f });
transform = glm::scale(transform, { size.x, size.y, 1.0f });

This change optimizes the matrix calculations code by refactoring how matrices are created and applied. Instead of repeatedly creating new matrices for translation, rotation, and scaling, it now efficiently applies these transformations to a single matrix. As a result, this change optimizes the performance of matrix calculations, leading to a 2.4x improvement in execution times.

Additional context

This is the test i have done: And this is the result:

I know its not much but hey, it's essentially free performance.

[kafkaphoenix]

you can also do glm::mat4 transform = glm::scale(glm::translate(glm::mat4(1.f), position) * glm::mat4_cast(rotation), scale);

[VagueLobster]

Idk, where you get this "free performance" from... I tried using your code in Hazel with 10000 sprites, and it's slower than what Yan is already doing 9/10 times on my PC!

[hanion]

Idk, where you get this "free performance" from... I tried using your code in Hazel with 10000 sprites, and it's slower than what Yan is already doing 9/10 times on my PC!

I see. I tried this with 100000 sprites and noticed a big improvement, so I decided to make the test. And with the results I got, I thought it might help Hazel too. But it's possible that the impact varies depending on the computer or other factors.

[VagueLobster]

I see. I tried this with 100000 sprites and noticed a big improvement, so I decided to make the test. And with the results I got, I thought it might help Hazel too. But it's possible that the impact varies depending on the computer or other factors.

That's exactly what i thought, that it might depend on which PC the user has 👍

[SimonMaracine]

Make sure that you test this compiled in Release mode. And taking a look at assembly output might be a good idea.

[VagueLobster]

Make sure that you test this compiled in Release mode. And taking a look at assembly output might be a good idea.

If you mean me, then i was in release and it did not help at all...

[hanion]

Thanks. It seems the performance impact varies by computer and might not be significant enough. Closing his request.

[SimonMaracine]

Make sure that you test this compiled in Release mode. And taking a look at assembly output might be a good idea.

If you mean me, then i was in release and it did not help at all...

Everyone, not just you. My intuition tells me that the compiler might optimize the code anyway, such that Cherno and hanion's machine code are similar. That's why I proposed looking at the assembly.

[VagueLobster]

Everyone, not just you.

👍