Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why must Keyframe<T>.value() be T: Copy? #15

Open
TheButlah opened this issue Mar 9, 2022 · 2 comments
Open

Why must Keyframe<T>.value() be T: Copy? #15

TheButlah opened this issue Mar 9, 2022 · 2 comments

Comments

@TheButlah
Copy link

Why must T be Copy? How can one access a value in a keyframe with non-copy types?

@TheButlah
Copy link
Author

I believe the motivation here must be to avoid unnecessary allocations. This makes sense as allocating on each tween would be crippling for performance.

Perhaps instead of returning an owned type, the caller to ease() could pass an output: &mut Self? That would allow for tweening types that are non-copy, by writing into the output.

@hannesmann
Copy link
Owner

I believe the reason for ease() working with values rather than references is that the former is better for primitive types. An f32 is smaller than a pointer on 64-bit processors, and it should be slightly faster since no dereferencing is needed.

Tweening primitive values or small structures seemed like the most common use case to me at the time, but the current design obviously has some downsides for larger structures or structures that can't be copied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants