* 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.
* Parsing issues updated.
* Updating the error docs to give them more information.
* Convert all the .md files to UTF8 to be more friendly with tools like Github.
* PR CR feedback.
* PR CR feedback.
* 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.
ref structs that are passed by "in" and have methods called on them end up being copied by the CLR to ensure the method doesn't mutate the value. Putting "readonly" on a ref struct avoid this.
This changes the code produced by the compiler and will have tiny perf benefits, but mainly it makes it easier to reason about what's happening under the covers with this struct.
The Reader is a ref struct, just like System.Text.Json.Utf8JsonReader, but under the covers still uses the Newtonsoft JsonReader. This gets us another step closer to switching over to System.Text.Json.
Break up the huge LottieCompositionReader into separate files so make it easier to reason about. This is being done now so that we can get ready to switch to System.Text.Json.
This also permanently turns on checking for unparsed fields seeing as we were always doing that anyway.
Apart from some renaming, the parser should work exactly as it did before. Subsequent commits will attempt to improve the code and get it better aligned with what System.Text.Json will need, before we finally switch over to System.Text.Json.
* Simplify node naming.
Previously we special-cased the naming of the root node and the root progress animations during codegen, but did some other special naming during translation. With this change we do all of the special naming at codegen time.
This change also includes better handling of name collisions in the node namer. If 2 or more nodes get the same name, we have to append a counter value to the name to differentiate them. Previously we appended a counter even if there was only 1 node, in order to prevent C++ from getting confused when a method name was the same as a type name. Now we keep track of whether a name is also a type name, and can therefore avoid appending the counter more often. This makes for much nicer naming (i.e. they don't have a _0 suffix) for most singleton objects.
* Use nameof to keep Yaml field names in sync with Lottie data property names.
Some of the Yaml field names were wrong. This change gets rid of the hand-written strings and replaces them with nameof(...) so that the names stay in sync with LottieData.
And did some small cleanup and refactoring while I was there.
This does change the Yaml output from what it was - that is intentional.
* Set a smart default value for property-bound colors.
Previously we always set property-bound colors to red to make them visible. With this change we are a little smarter about it: we show the color the designer used, and if that color was animated we find a high-alpha color amongst the keyframes the designer used.
* Optimizations for generated code.
1. Call a method to bind an animator to Progress.
2. Call a method to bind a property to an expression.
* Generalize to handle more cases.
* Do the starting of an animation and binding to progress in one method.
* Optimize generated code for collection population.
If a collection (e.g. Shapes or Children) has only one child being added, don't both creating a local for it, just add it directly.
This change is designed to make the generated code a bit simpler.
This change makes the YAML output work better with YAML editors (in particular VS Code) when they collapse sequences. Previously a collaped item in a sequence would be invisible until it was uncollapsed. Now, you'll see a comment for the item.
To take advantage of this new behavior, the Lottie yaml serializer now adds a comment containing the name of each object.
And we no longer display the MatchName field (as it's rarely used and is meaningless to us).
The result is that Lottie YAML files are much easier to navigate, as you can collapse parts of them to get an overview without losing information about what the collapsed items are.
* Transfer object descriptions and names during tree reduction.
Tree reduction is an optimization on the Composition graph where we attempt to coalesce and remove redundant visuals and shapes. Previously this resulted in the loss of some descriptions and names on objects. Now we attempt to transfer that information out of the objects that are being removed into the objects that are taking over their roles.
The root progress animation expression ("_.Progress") is used to synchronize (almost) all of the animations in a Lottie. It is handy to be able to recognize it in the code.
Opacity is special because it's expressed in Lottie as a percent, which is inconvenient for multiplication with alpha.
Giving an Opacity a strong type allows us to abstract the percent details, and also make the translator clearer because it's obvious where a value is being used for opacity.
Simeon
Simeon
James Croft