You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 3, 2020. It is now read-only.
Conceptually, it seems that when CAAnimation.additive is set to YES, lack of fromValue should result in animation starting with 0 (whatever it means in the context of particular property. For example:
Without knowing the underlying architecture, I'd assume that from consumer point of view, not assigning fromValue when additive animation is enabled should produce animation from the current state to toValue.
If my guess about the reason is correct, fixing this might require a somewhat large switch statement going through all possible property types and suggesting default values (e.g. @0 for numeric types, CGPointZero for CGPoint, not even sure what should it be for property of CGAffineTransform type)
But before getting into engineering aspect of it, I'd love to hear some other perspectives - am I'm the only one who has this expectation?
The text was updated successfully, but these errors were encountered:
Seems valid to me, but I can also see an argument for always starting from the property's current value being simpler. If nothing else, though, deserves to be documented that you'll want to set fromValue as well as additive.
Conceptually, it seems that when
CAAnimation.additive
is set toYES
, lack offromValue
should result in animation starting with0
(whatever it means in the context of particular property. For example:produces funky result. (I'm guessing it happens due to animation implicitly copying initial position to
animation.fromValue
)Following addition fixes it
POPBasicAnimation *animation = [POPBasicAnimation animationWithPropertyNamed:kPOPViewCenter]; animation.additive = YES; + animation.fromValue = [NSValue valueWithCGPoint:CGPointZero]; animation.toValue = [NSValue valueWithCGPoint:CGPointMake(offset, -imageView.center.y - 40)]; animation.duration = duration;
Without knowing the underlying architecture, I'd assume that from consumer point of view, not assigning
fromValue
whenadditive
animation is enabled should produce animation from the current state totoValue
.If my guess about the reason is correct, fixing this might require a somewhat large switch statement going through all possible property types and suggesting default values (e.g.
@0
for numeric types,CGPointZero
forCGPoint
, not even sure what should it be for property ofCGAffineTransform
type)But before getting into engineering aspect of it, I'd love to hear some other perspectives - am I'm the only one who has this expectation?
The text was updated successfully, but these errors were encountered: