- Replace is null usages in generated code with downlevel equivalent to support older versions of C# in client applications
- Fix MSBuild task to send bool args correctly. The LottieGen cmdline only allows flags to be set without an associated value arg.
* Added support for animated round corners modifier
* Fixed typo and epsilon calculation
* Typo fix [2]
* Added new issue code LT0043 + more comments in the code
- Parameter validation no longer fails on valid params
- Fixed props fle path to LottieGen dll
- Fixed path generation for LottieGen exe
- Converted parameter types which are not supported by MSBuild to acceptable types
- Added escaping to command-line args to avoid mangling file paths
Error reported:
Microsoft.Toolkit.Uwp.UI.Lottie v7 uses System.Text.Encodings.Web v4.7.1 which has a high severity security vulnerability and as such doesn't pass component governance
This upgrades all of the runtime NuGet packages to the latest version.
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.
With this change, we'll produce a new nuget package that contains the LottieGen.exe executable built into a single file with no dependencies (not even .NET) and an MsBuild task.
This is being done to enable LottieGen to be more easily used in a build.
* Create a project just for the animatables.
The animatables are types that are used by both LottieData and the upcoming
intermediate representation, so we need them to be in a separate project so
the code can be shared.
This also adds some small features to some animatables for use by IR, and
changes some IAnimatableVector3 types to IAnimatableVector2 (e.g. gradient
stops should never by vector3.
I've also removed the "property index" from animatables. That is a Lottie concept
that is only needed if you are supporting javascript expressions. We will never
support javascript expressions, so they're not needed. Removing them makes the
code a bit cleaner.
* Add support for WinUI 2.6 animated icon.
This also removes the ability to set a custom interface in place of the WinUI
interface, because nobody seems to need it now, and it adds a bunch of
complexity.
Marker names don't have to be unique, but it's usually a bug if they are, so issue a warning if non-unique markers are found.
LottieGen didn't have validation turned on for some reason - now it does.
Small tweak in the DGML output: give LayerVisual its own category. This allows it to be displayed with a unique color.
* Add support for LayerVisual and DropShadow Composition types. Much cleanup.
Getting ready to actually support DropShadow - we need some Composition types added.
As a result of adding the Composition types, I noticed many small cleanup tasks and included them.
Fix issues caused by update to VS 16.8 release.
Remove NullablesAttributes workaround for .NET Core 3.1 projects.
Now that we are building the .dll projects with .NET Core 3.1, the NullablesAttributes project is redundant and conflicts with the built-in nullables support in .NET Core.
* Generate a way to convert between marker names and progress values, and set bound colors.
To use this without having to cast to a particular class type, use the -AdditionalInterface command line option in LottieGen.
Cppwinrt example:
LottieGen.exe -inp MyLottieFile -AdditionalInterface MyNamespace.IMyInterface -l cppwinrt
...then in your cppwinrt project, add an IDL file that defines MyNamespace.IMyInterface and declares the methods you want to access, e.g.:
namespace MyNamespace
{
interface IMyInterface
{
Windows.Foundation.Collections.IMapView<String, Double> Markers { get; };
void SetColorProperty(String propertyName, Windows.UI.Color value);
};
}
...and finally, reference the interface from your code with an include of "MyNamespace.IMyInterface.h".
* Add ability to specify additional interfaces for the generated code.
This adds a feature to LottieGen to specify interfaces that LottieGen will then claim that the generated class implements.
This feature allows you to access methods that we generated on the class that are not members of IAnimatedVisualSource. This provides a way for us to add new features to the generated code, that can be accessed without knowing the exact type of the generated class, and without us having to update the IAnimatedVisualSource interface.
For example, I am about to add some metadata methods:
double GetMarkerAsProgress(string markerName);
void SetColorBinding(string bindingName, Color color);
Cool, but how do you access those methods? If you know the type of the generated class (e.g. "MyCoolLottie") then you can just call the methods on a variable of that type. But what if you want to call one of these methods without knowing the type? Or maybe you want to treat all your generated code in the same way, so the types get in the way.
The solution is to tell LottieGen that the generated code supports an additional interface that you will define to contain the new methods. LottieGen will then say "sure, the generated code implements "MyCoolAdditionalInterface". As long as your interface's methods are the same as the ones that we generate, you'll now be able to use MyCoolAdditionalInterface to call those methods.
* 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.
* cppwinrt codegen refinements.
This is in response to user suggestions:
1. Use non-namespace-qualified names for the names of the *.idl, *.h, *.cpp files. Previously we were qualifying them with namespaces as cppwinrt does, but user preferred non-qualified.
2. Add a -RootNamespace option to LottieGen that corresponds to the same option in cppwinrt.exe. When cppwinrt.exe is given a root namespace, the names of the files it generates has that namespace stripped from them. This option in LottieGen affects the names used in the #includes that include the cppwinrt.exe-generated code.
This is not complete (IDynamicAnimatedVisualSource code will not compile). However it fixes a number of IDynamicAnimatedVisualSource issues.
Also gives unique names to the AnimatedVisual classes. This should make callstacks clearer in C++.
* LottieViewer: allow palette colors to be changed, and markers in the info panel.
This change required more space for the color picker, and that it didn't cover up the playing Lottie, so the info and play speed and color picker are all now implemented as panels that slide out from the right.
* Refactor to allow better modularization of the translator.
Previously most of the translation code had to be in the LottieToWinCompTranslator class and that was making it difficult to maintain.
The goal with this refactor is to allow translation code to be implemented in static methods grouped for convenience into static classes, and to avoid having to pass more than one context to a translation method.
The state that is needed for translation is now in various "contexts". The LottieToWinCompTranslator is now just a static class that creates the top-level context and tells it to translate.
Previously we had a "TranslationContext" that was the context for translating a layer, and a "ShapeContext" that was the context for translating a shape withing a shape layer.
Now we have:
TranslationContext - context for stuff that is global to a particular Lottie file's translation.
CompositionContext - context for a list of layers. There is a CompositionContext for the root of the Lottie as well as one for each PreComp layer.
LayerContext - context for stuff that is layer dependent. There are strongly-typed subclasses of this for each layer type.
ShapeContext - as before - context for translating a shape.
These contexts form a hierarchy: ShapeContext contains a LayerContext which contains a CompositionContext which contains a TranslationContext.
Contexts inherit state from their containing context.
Through the magic of implicit conversions, a context can always be passed to a method requiring a context type higher in the hierarchy, e.g. a LayerContext can be passed to a method that requires a TranslationContext.
This switch is intended to exist only until we fork LottieGen to be WinUI3 only. Until then it is a convenient way to have the code generator output code that needs little hand tweaking to work with WinUI3.
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.
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.
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.
* 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.
* 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.
* Improve NodeNamer readability.
This is a follow-up from a previous PR where there were some questions about the NodeNamer, so I've refactored it to take advantage of C# switch expressions and added better comments.
Also move LottieGen to .NET Core 3.1 (was 2.2). This means we can use newer features, and we get an actual exe rather than having to use the "dotnet" bootstrapper.
* Fix typo found in CR.
* CR feedback.
* Fix issue found in testing.
* Another issue found in testing.
* Fix comment.
* More support for property bindings.
Add support for Color values in CompositionPropertySet.
Add support for TryGet* methods in CompositionPropertySet.
Refactor the CompositionPropertySet implementation so that it's easier to add new types.
Adds a switch to the translator to determine whether or not it recognizes property bindings. Property bindings are only useful for codegen so this switch is off for LottieVisualSource and on for LottieGen.
Translator will now insert a property for a solid color fill that has a property binding for "Color".
* CR feedback.
* Move codegen code into its own module so that projects that don't use codegen don't include it, and so we can start using C# 8.0 in the codegen code.
* Pass Lottie metadata (frame rate, etc) through translator to the code generators.
Add ability to convert GenericData object to code-genned Windows.Data.Json objects.
This change passes the data through but doesn't yet change the output of the code generators. That will come soon when we figure out what clients would like to have.
* Remove some dead code.
* Removing C#-8.0-ism from code used by UWP.
Switch expressions are new in C# 8.0. UWP requires C# 7.0 so the LottieVisualSource won't build with them.
Now that LottieVisualSource doesn't support codegen, we should refactor this so that codegen can use C# 8.0 (which is ok for LottieGen because it's .NET Core so can use C# 8.0).
* Remove another piece of C# 8.0 that snuck in. It breaks LottieVisualSource builds.
* Make parsing resilient to issues seen in our corpus.
Handle unexpected matte types by parsing as "Unknown" and treating them as Add.
Allow parsing errors in layers to result in the layer being ignored rather than giving up. Note that this can result in an issue later on if the layer is searched for but not found.
Handle case of a layer with inPoint == outPoint by ignoring that layer.
Fix comparsion of CubicBezierEasings - equivalent CubicBezierEasings were being reported as being non-equal due to missing == operator overloads.
Handle the case of multiple color gradient stops at the same offset - always use the last one. Designers might do this because in one keyframe the stops are all bunched up against offset 0 or 1, then later they get spread out.
In general, throw exceptions from the parser less often.
Parse and save any extra top-level data in the json file. I plan to expose this in generated code and LottieVisualSource in a later check-in.
Alexandre Zollinger Chohfi
aborziak-ms
Aaron Schultz
Simeon
Simeon