craftworkgames
Expose Tweens
Hi
I was wondering if it would be possible to expose the Tween list used inside the Tweener. Would be useful to know, for instance, when all tweens had finished processing
@AristurtleDev and other Devs/Mods,
This request seems pretty straight forward. If the requestor @bootzin just needs to know if the tweens are finished, then I think A or B should solve that without exposing the behavior of the private member _activeTweens. If @bootzin really does still need access to the underline private member, and we want to go that route, Option C could be performed.
It appears a public variable AllocationCount was added in 2018 in this commit:
https://github.com/craftworkgames/MonoGame.Extended/commit/5e3cbb3109945b3005b28e060c4d0e3ccedffebe#diff-3a4b830fec3aaaec78ec00828bcf2a630ccecf43acc51a27a29621a6a0c685e6
This variable I would assume was intended to be the count of active tweens (unsure?) It also doesn't appear this variable is ever subtracted from, or used anywhere else in the entire library.
Options off the top of my head:
A) Add a AllocationCount--; on line 70 so that this variable correctly shows how many active objects there are:
https://github.com/craftworkgames/MonoGame.Extended/blob/080f5e1f23ed25e0011c7d6471b3e37fada85c30/source/MonoGame.Extended/Tweening/Tweener.cs#L70C2-L70C47
B) change AllocationCount into an expression-bodied member instead like public long AllocationCount => _activeTweens.Count;
C) Expose the private List of Tween _activeTweens
Thoughts from anyone?
It does look like AllocationCount was initially meant to keep track of the number of tweens created. It's only incrementing when a new Tween is created and added to the _activeTweens list. I'm not sure what the original purpose of this property was, since it's only ever incremented and never used anywhere. Maybe a left over idea that Dylan never finished?
As for exposing the private member, this can be debatable. I personally prefer design to show intent over just exposing everything and letting the end user make their own mistakes. For instance, List<T> is not thread safe, and it's also used in for loops during the Cancel* methods, so you wouldn't want anything modifying the list during these scenarios.
Given we're on .NET 8 now, and all the new wonderful things with Span<T> would could expose the list that way by doing something like
pulbic Span<Tween> ActiveTweens => CollectionMarshal.AsSpan(_activeTweens);
This is a zero allocation return of the underlying collection from the list as a Span<T> that can be used to check on the current active tweens and get information about them without risking exposing the internal implementation design.
cc: @craftworkgames/monogame-extended
Looking over this and #992, the Tween system needs to be re-evaluated as a whole and refactored for better performance. Going to move this tot he v7 milestones for now