* CX classes stopped compiling because it wasn't public. Make it public.
Apparently something changed in the way XAML gets info about CX classes - it used to compile but now it won't compile unless the classes are public. Public classes publish their metadata, which is presumably how XAML is now getting info about the classes. This change makes the CX classes always public.
This is in response to issue 320, where a user was concerned about LottieGen producing non-deterministic output from a build run on different machines.
With this change, we'll no longer include path information or information about where or when the tool was run, and the only thing special that TestMode will do is remove the tool version from the output.
We were generating a return after each version check instead of checking all the versions before returning. As a result, we'd only run on the highest supported version.
When LottieGen generates color bindings automatically, it creates WinRT properties for each distinct color in the Lottie. The names of these properties were using the descriptive color names which are great for trying to understand code, but they're unnecessarily complex for property names. For example, naming a color AlmostTurquoise_FF123456 is including information about the color that the user doesn't care about. The user simply wants to identify which property is which. So now we just output "Color_XXXXXX" where XXXXXX is a 6 digit hex represenation of the color, ignoring alpha.
This change also fixes a bug I noticed during testing where the enumerators for sliced lists were never created.
* Recognize animation subchannels when discovering non-default properties.
This problem has always existed but it didn't matter until we started using subchanel animations for Scale (Scale.X and Scale.Y) in order to support multiple easings.
The issue was that we ask which properties have non-default values by looking at whether the property is set, and whether there is an animation for that property.
But when we find animations for a property we need to ignore the subchannel part of the name (the ".X" part).
This has been bugging me for ages. It was an attempt to switch the code over to using Span, but in the end it didn't make thing better, and required extra indirections to get at the items in the sequence.
While I'm here I'm adding some other nice touches, including avoiding copying of arrays when create a sequence, and allowing the creation of a sequence from a single item.
Very rarely the generated code contained name collisions as a result of a name having the same form as a name with a counter suffix, e.g. Rectangle_15 looks like a name with a counter suffix but it might just be a 15x15 rectangle.
We now check for collisions when adding a counter suffix.
Lottie allows Vector2/Vector3 to have different easings for each channel. When that happens we cannot translate
them as Vector2/Vector3 animations, because WinComp only supports an easing for the whole Vector2/Vector3.
Now we will recognize this case and first translate the AnimatableVector3 to an AnimatableVectorXYZ and
create separate animations for each channel.
This change only supports separate easings in that cases that we've seen in the corpus. Complete support is
a lot more expensive code (i.e. expensive to maintain because it requires a lot of repeating of the same
patterns over and over with slight changes).
Current support includes:
* Size of a shape
* Size of a rectangle
* Radius of an ellipse
* Position of a shape
When enabled with -GenerateColorBindings, LottieGen will create bindings
for each non-animated color it finds in a fill or stroke. This will
allow the colors to be changed at runtime.
This is particularly handy for animations that have a single color such
as those found at https://www.lottieflow.com.
The feature is less flexible than theme property bindings because:
a) it only supports colors
b) it doesn't give the designer much control over which parts of the
animation are bindable.
c) it doesn't allow the designer to choose the names used for the
bindings.
The binding name is the color, so a black color will generate a property
called "ColorBlack".
For single-color Lottie files we could be clever and name the property
"Foreground". I'm not doing that right now because we don't yet know
how the feature will be consumed.
This way of translating paths applies rarely, but when it does it solves a couple problems:
1) It enables some animated paths to be rendered on UAP versions < 12.
2) It is more efficient than animating a path.
It's a mystery as to what this field does. It appears to be related to miter limit, but that's already handled by "ml". Some tool is adding it, although BodyMovin importer doesn't seem to know what it is.
CompositionRectangleGeoemetry doesn't anti-alias correctly. Rounded rectangles with tiny corner radiuses work fine, so use them instead.
Rectangles are expected to be fixed eventually, and when they are we can take advantage of their better (than rounded) perf, but until then they aren't reliable.
And fix a bug in the NodeNamer I found during testing.
This is to make it easier to see from the factory method for a gradient where the gradient stops lie.
I'm adding this because I started investigating why gradient stops are sometimes different from run to run of LottieGen and realized that this change would make reading the generated code easier to help figure out what's going on.
Ignore the "meta" field in Lotties.
Previously we would complain that this field is unexpected. It's an object added by the LottieFiles.com plugin. We don't do anything interesting with it yet, but at least we shouldn't frighten the user with a warning.
Add a CubicBezier type to describe easings and spatial Beziers.
And make the keyframe optimizer not remove adjacent keyframes that have the same value but have non-linear cubic bezier easings.
The XML outputs aren't being used by anyone AFAIK. They have a maintenance cost and they unnecessarily increase the number of files we generate during testing which slows down testing.
So I'm removing XML completely. For WinComp the C# outputs are higher fidelity and easier to read. For Lottie the YAML outputs are much easier to read.
These old XML outputs were useful in the early development of this project but they have no value now.
I found a Lottie file that during translation would generate 2 keyframes at the same progress. That's illegal for Composition.
The Lottie file that triggered this had one path in a geometry group at frame 48 and another in the same group at 48.000000357.
This issue is caused by the fact that we convert unique key frame numbers as doubles to progress values as floats. Floats have less resolution, so if 2 keyframes were really close together then they might end up with identical progress values.
It's also an issue when we group animated paths because the 2 paths might have key frame numbers that are slightly different but end up at the same progress value. As long as we prevent identical progress values that's fine, but if we can be a bit smarter about how we compare frame numbers during grouping we can group more effectively.
* Rename to match After Effects and some initial refactoring.
* Correctly support roundness where size and roundness are not animated.
* Handle non-static rounded rectangles better.
* Also fixes a misunderstanding with how animations are stopped in Composition.
* Simplified factories for some common cases.
This simplifies the codegen for the creation of some objects. This results in smaller
outputs and a slight perf improvement.
* Make writes to the console transactional where necessary.
The recent output coloring made the problem obvious - when we run Lottiegen over multiple files there are numerous threads that are writing to the console and can interleave their writes.
With this change, the writes that need to be kept together have a way of being kept together.
Drawing direction determines where the path of the shape starts and ends. This matters when trimming the path. I think that if the shape is closed (e.g. an ellipse) and the drawing is in reverse
then the trim start and trim end get swapped. Still trying to figure out all the details.
There will be at least one more change to support drawing direction. This is just to get the
bones of the parsing in place. Following changes will use it during translation.
Note that the enum values don't have descriptive names because I'm not sure what they should be yet.
Also, fixing a bug in the NodeNamer that caused it to add leading 0's to object counters unnecessarily when there were exactly 10/100/1000/etc objects.
* We were ignoring the "closed" property on paths.
In most cases, a closed path is simply one that ends where it starts, so we just left all our paths open and relied on After Effects to complete the path.
But that was wrong in some cases - specifically the closing of the path determines whether a miter or an end cap is used where the end meets the start.
* Improve handling of grouped animated paths.
This change will allow some (not very common) cases of grouped animated paths where the animation can be optimized away or ignored.
In the cases it can't be sure that it can handle, it now raises an issue to make it clear that there is a problem.
* Updating issues docs to integrate old changelist.
Sohum created some changes to these issues docs last year. I'm
using them as inspiration to update our docs, and to deprecate another
issue.
Simeon
Marcel Wagner