Closed vanniktech closed 3 weeks ago
I also thought about that. But then I'd kind of rely on the implementation that's inside Lottie. If that changes for some reason, I'm screwed. iOS also offers to get the original size:
Also after dividing, I'd need to round it (I want the integer value).
Can you divide the returned width/height by
Resources.getSystem().getDisplayMetrics().density
instead? That's all the scaling is doing.
The implementation of that definitely won't change. I'd like to keep the API surface area of Lottie as small as possible. If the difference here really is dividing by that number, I would prefer not to add it to the core library.
The difference is by dividing that number and needing to round it which may yield 399 instead of the original 400 depending on the scale and the rounding mode. It's really not a lot that is added to the API surface, has parity with the iOS implementation and yields something that is part of the format.
Do you also want me to prefix the exposed API with unscaled
?
Do you also want me to prefix the exposed API with
unscaled
?
Yes, please!
Should be good to go now.
Use case: I just want to know the unscaled original height / width of the LottieAnimation. I want to do my own scaling by calculating for instance given an aspect ratio or weighted settings, how big/small I can stretch the animation.