[FEATURE REQUEST] mutable graphene operations

[ranfdev]

Let's take Vec2 as an example: most operations are similar to fn op(&self, &Vec2) -> Vec2. But If I have an array of vectors (which is mostly always what I need to squeeze maximum performance), I can't apply any of those operations on my vector inside the array, because the operation doesn't mutate in place.

If I have an array of 1000 Vec2, creating a copy at each frame is going to destroy the performance of my app.

The graphene C API can work in place (or at least it can put the result to a user specified pointer).

[bilelmoussaoui]

We have normally manual implementations for the setters. I have probably missed some, feel free to send a patch

[sdroege]

If I have an array of 1000 Vec2, creating a copy at each frame is going to destroy the performance of my app.

I don't think so. Updating a Vec2 should be quite optimizable for the compiler and effectively do the same as if you had setters.

But for nicer usage having setters would be nice.

[ebassi]

I'd like to point out that SIMD types are not mutable by design: accessing single lanes to change stuff destroys any performance advantage those types provide.

Every SIMD operation, down to the assembly level, returns a new value; you can pass the address of the original variable to replace its contents wholesale, but that requires passing around stack allocated values, and never heap allocated ones. In any case, you still get a whole new vector.

[jf2048]

I can't apply any of those operations on my vector inside the array, because the operation doesn't mutate in place.

You can mutate the array by doing array[i] = array[i].add(x).

Can we close this issue and move it to upstream graphene?