This is mostly a find-and-replace of the == null and != null checks.
This makes the code consistent, modern, and safe from equality overloading errors.
I have not replaced them in the generated code.
I have made the C# generator output the "is not null" pattern.
* Enable nullable reference types where possible.
This enables C# 8 nullable reference types. Many files have nullables disabled so I don't have to fix everything at once. I'll get them all enabled bit by bit. All new files default to nullable now.
* 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).
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.
* Add theme property binding. Code gen improvements.
* Add -Public switch to LottieGen to optionally generate public classes. By default the generated classes are "internal" which is ok for most projects, but if the generated code is being built separately from the code that consumes it then the classes need to show up in metadata, which requires that the classes are "public".
* Restrict the generration of PathKeyFrameAnimations to UAP version 11. PathKeyFrameAnimations are not reliable before version 11.
* Expose the generated ColorAsVector4 method so it can be used by code that hosts the generated code. This makes it clearer to clients how they should convert colors to Vector4 in order to set the values in the theming CompositionPropertySet for colors. (This is about working around the inability for animations to reference the R, G, B, or A subchannels of colors).
* Expose theme property default values as constants. This allows apps to get the values without having to instantiate the source object.
* Give greater details in comments in the generated code to explain the purposes of matrices. We use matrices a lot to do simple scaling and offsetting because it allows us to generated tighter code, but the matrices are hard to read without comments.
* Clean up of the code generator to generalize default-valued properties - we now rely on the optimizer to unset properties with default values. We should only be doing this optimization in one place, and optimizations belong in the optimizer.
* Optimize away some stroke properties that we can prove are not needed (in the GraphCompactor).
* More resilience for the Lottie reader - handle a json exception in a graceful way.
* Order fields in generated code by type name then by name. This became necessary because some of the fields are getting more descriptive type names which caused the types of the fields to be ungrouped.
* Fix bug in miter limit. Would cause very large miters under some rare circumstances. The WUC miter limit is specified differently from the Lottie miter limit and we weren't taking that into consideration. Specifically the WUC miter limit is a ratio relative to half the stroke width, while the Lottie one is relative to the whole stroke width.
* Implement one remaining case for composing visibility in Visual tree chains.
* Give better names to the animations used for shape visibility.
* Add optimization to push visibility up the tree. This increases the chances that we will be able to convert a Shape tree visibility (which is implemented with a Scale) to a Visual tree visibility (which is implemented directly as Visibility), and that we can discover common visibilities further up the tree.
* Generate constexpr and "internal" visibility for constants on CX.
* Expose markers as constants. This should eliminate the risk of a dev integrating generated code from not updating the segment timing after the designer changes the segment timing.
* Make the graph compactor keep iterating as long as the tree changes. Previously it was as long as the tree was getting smaller, however some new optimizations don't make the tree smaller, just better.
* Added ability to "unbind" an animation from a WinCompData object. Needed in order to move an animation while keeping the original object. This is needed to allow animations to be pushed up the tree during graph compacting.
* Added a general table formatting system for generated code. This allow us to easily create comments that contain tables. We currently use it to list markers, theme properties, and the counts of expensive objects.
* Add a lot more detail into the code generation comment at the top of files. The goal is to be able to identify which version of a JSON file, and what switches and build were used. This should help reduce confusion when there is a lot of iterating going on with a design. It makes it clear in diffs if someone changed the codegen options, or if they changed the input, etc. It also gives a command line that can be used to generate the code in the same way next time.
* Add "TestMode" to lottiegen to produce outputs that do not change on each invocation (no tool version, no paths, no timestamps). This is necessary to allow testing via diffing between old and new versions of Lottie-Windows code now that we have timestamps and paths in the generated code.
* Remove old dead code from the translator.
* Make the properties on CompositionClip and InsetClip and all Clip properties nullables, to be consistent with most of WinCompData.
* Add optimization to push shape visibility down the tree. This increases the chance that we can combine visibility with some other property and enable a reduction in size of the graph.
* Canonicalize progress remapping variables. These are the "t1", "t2" etc properties in the root property set that are used to remap time for our spatial animation translations. Previously we could end up generating duplicate properties and animations for time remapping variables.
* Make the graph compactor keep iterating as long as the graph is shrinking. Previously we would iterate some fixed number of times, assuming that it was too expensive to iterate more than necessary, so we erred on the side of under-iterating in some cases. But nobody is complaining about graph compaction time, and for codegen it doesn't matter, so we might as well let it run.
* Improved the ToString() on some CompositionObjects to make them easier to see in the debugger.
* Adding support to WinCompData for BooleanKeyFrameAnimation and Visual.IsVisible.
* Enable IsVisible animation for visiblity on Visuals. Previously we were using opacity, but this now frees up the opacity property for doing group opacity (sometimes, when we get lucky - we can't currently do it in general because the shape tree doesn't support opacity).
* Bug fixes in GraphCompactor. In particular we were being too aggressive about coalescing ContainerVisuals that were directly under CompositionVisualSurface. Turns out that transform properties are always ignored on the visual directly on CompositionVisualSurface, so we always need a ContainerVisual there with no transforming properties.
* Optimize away keyframes for redundant gradient stops.
* Recognize and remove redundant gradient stops. This is especially useful for getting rid of redundant "midpoint" stops that are inserted by After Effects.
* Adding count of Animators to the stats report. This is intended to be a (rough) estimate of costs to help designers know if they are making things more expensive as they change their designs. CPU usage in the animations engine approximately scales with the number of animators, so this number should be a rough indication of animations engine cost.
* Translator refactor: use CompositionSubGraph for Shape layers to defer the decision about whether to translate to a shape or a visual. Previously we would generate a layer to either a shape or a visual then figure out how to combine the generated layers depending on what was generated. Now we ask each layer to generate to a shape or a visual, so the layer combining is in control of what gets generated, rather than being a victim of it.
* Add helpers methods in the codegen to reduce code size. These make a big difference as there are some common patterns that we do a lot.
* Switch to Scale animation rather than TranformMatrix for visiblity on shapes. This is cheaper because it requires only one property to be animated (TransformMatrix required 2). This also allows more optimization in the graph compactor because the graph compactor can recognize this pattern for visibility and can push it up or down the tree.
* Adding optimization to eliminate many "Position" animations. If position is animated but anchor isn't, we can convert it to an Offset animation - which is what we do now. That saves us having to create an ExpressionAnimation to relate the anchor and position to the offset.
* Squish the expression animation strings to save some bytes.
* Added ability to the code generator to lazily create helper methods (and in general to create source out of order via sub-CodeBuilders). This allows helper methods to be inserted in code gen, but only if needed, and without us having to analyze the graph in advance to determine whether they're needed.
* Refactoring many InstantiatorGeneratorBase methods for improved readability.
* Canonicalize brushes used for theming.
* Canonicalize animated paths.
* Support CX codegen for DependencyProperty property bindings.
* Add ToolInfo class to communicator info about how the code was generated from the command line interface through to the code generator.
* Add -GenerateDependencyObject for property binding.
* Support theme property binding of StrokeWidth on any Lottie stroke.
* Get theme properties working for all languages (CX, C#, and cppwinrt).
* Add -namespace options to LottieGen. This allows code to be generated into the namespace of your choice. Defaults to the "::AnimatedVisuals" namespace.
* Add a differentiation to the names of CX files if they're being generated at the same time as cppwinrt. This is needed for testing where we generate files and diff them. Without this change the file names would clash.
* Fix issues discovered during testing.
* CR feedback.
* Fix bugs introduced by CR changes.
Update some incorrect licensing headers in source files.
* Fix build breaks.
* Fix the reference to the package certificate so that it will build.
* Completely turn off signing to allow build to succeed.
It was off before and was turned on accidentally.
* CR feedback.
* Remove unnecessary checks for default values.
These checks were needed before to avoid setting properties that have default values, but now we have an optimizer dedicated to unsetting properties that have been set to default values, so there's no need to check anywhere else.
* PR feedback.
* PR feedback.
Also ran the VS cleanup and analysis tools.
* PR CR feedback.
* Make Expression objects have stronger static types.
This change allows more static checking for animation expressions.
The Expressions objects previously supported generic types and type inferencing because when this was first written it seemed like they would be used for a more general expression parser, but it meant that the type of an expression wasn't statically known. With this change, every expression has a static type, which allows stronger typing wherever an expression is used, and allows the C# type system to find some bugs in our use of expressions.
I found 2 bugs as a result of this - one that affected 2 Lottie files in our corpus (it produced code that would fail at runtime), and one that affected a codepath we never hit (it made it obvious that this codepath is never hit).
I've run this over all of our corpus and the results are exactly the same as before, apart from the 2 files that were hitting the bug mentioned above. So there are definitely no regressions for all known Lottie files.
Switch to newest JSON parser.
Optimize allocations by using ReadOnlySpan<T> in places where we previously use IEnumerable<T> as a way of protecting arrays for modification.
aborziak-ms
Simeon
Simeon
Ibraheem Osama