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.
* Tweak the nudging factor for markers, and better UI for markers.
These changes are to improve AnimatedIcon workflow.
The nudging value of 0.01 was insufficient, so this ups it to 0.05.
The UI in LottieViewer for markers and the scrubber is confusing because it shows progress, which designers don't care about. So now it uses frames everywhere. Developers that need to convert to progress can do the math themselves (it's just (frame count) / (number of frames) plus a nudge.
* Make the arrow keys on the scrubber move by a single frame.
* LottieViewer UI now only deals in frames.
Seeing as LottieViewer is for designers, and they don't know about progress, the markers and scrubber will now only show frames information.
Also added more frame information to the Lottie properties.
Arrow keys now move by a single frame on each press.
* Fix the colors on hyperlinks and the playback rate slider.
The default colors for hyperlinks and sliders are themed, which can cause the colors to become unreadble on the gray background of the main page..
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.
Previously, you'd press the arrow keys 10 times before the tooltip value would change. That was confusing! Now the tooltip will always change in response to the arrow keys.
* 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.
They were causing certification issues because they had some color in them. But we don't need them because they're only for lock screen notifications, which we don't use.
* Add a new build configuration for a Beta version of LottieViewer.
The "BETA" build configuration will build LottieViewer with a different name and identity so that it can be released to beta testers and exist side-by-side with the non-beta version.
Add visual assets stamped with "BETA" to make it obvious that it's a BETA.
Because Lotties can render differently on different UAP versions, it's important that users know what version of UAP they're using. That way, when they say "this doesn't look right", and I say "looks fine to me", we can check the UAP version easily to determine whether that accounts for the difference.
* Allow external images to be loaded by LottieVisualSource, and add .lottie file support.
External images (i.e. images that are not embedded in the .JSON file) are a problem for LottieVisualSource because it doesn't know how to get them. For securit reasons, we don't want LottieVisualSource to have the ability to read files that are referenced from a Lottie .json file, and in many cases LottieVisualSource wouldn't be able to resolve the file because it doesn't have permissions.
This change adds an ImageAssetDelegate that the user can set on the AnimatedVisualSource in order to handle reading of external images.
This change also adds support for the .lottie format (see https://dotlottie.io). There is a parser for .lottie files, and support in LottieViewer for displaying Lotties from a .lottie file. Because .lottie files package images together with the .json Lottie file, it enables LottieViewer to display Lotties that have external images.
* Fix some bugs that were obvious when I started to CR.
* CR feedback.
* CR feedback.
* CR feedback.
* Fix typo in header.
* 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.
* 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.
* Adding markers to the scrubber.
This is a rewrite of the Scrubber to support markers. It also is a much nicer implementation of the
scrubber that reuses more of the XAML Slider functionality, and reduces the amount of copied XAML from
the default Slider style (from generic.xaml).
As I was adding this change, it became apparent that the way the XAML slider draws its track would
not work well with markers at 0.0 or 1.0 because the track ends up extending before and after the
0.0 and 1.0 positions which would make the markers look like they were incorrectly placed. So now
we do all of the drawing (track, decrease rectangle, and thumb) using Composition.
We also now mimic the mouse-over behavior of Slider so that the control feels a little more engaging.
This required hooking Composition into the VisualStateManager, which is achieved by replacing the
default VisualStateManager with our own implementation.
* 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.
* 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.
LottieGen has a lot of options for code gen. LottieViewer doesn't have a good way to make those options available. So rather than making LottieViewer more complicated, I'm removing the codegen functionality completely. When you need to codegen, use LottieGen - it's waaaaaay better.
* 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.
* Support gradient opacity stops.
In LottieData we now model opacity and color stops on gradients as a single list of GradientStop which can either be an OpacityGradientStop or a ColorGradientStop.
During translation, we convert that list to a list of ColorGradientStop where the opacity information is carried in the Alpha channel.
During canonicalization, work around an issue with CompositionColorGradientStopCollections which require that a stop object does not appear twice in the same collection.
When translating gradients, use the maximum opacity in cases where we can't support opacity animation. Previously we used the initial opacity, which caused things to disappear if they started out with 0 opacity. Maximum opacity will allow the items to show up, which makes it easier to debug.
Updated the temporary cert used when building LottieViewer - the old one had expired.
* Update the samples cert - it had expired.
* Update nuget dependencies to latest non-prerelease versions.
* Updating the version of .NET Core UWP support.
I had previously updated the Nugets for the solution, but apparently that's not sufficent.
* Preparing for implementation of gradients.
* Make LottieGenCorpus more deterministic.
Previously the output depended on the width of the console, and sorting ignored case.
* Upgrading to SDK 18362 (May 2019) so that we can use RadialGradientBrush.
* Add data representation of IRandomAccessStream for use by LoadedImageSurface.
LoadedImageSurface doesn't actually do anything with IRandomAccessStream yet.
Also tweaked the samples csproj to get rid of a warning.
* CR feedback, and fixing race in the build.
* Fix cake file.
* Work around race condition in the build.
* Fix typo on commen
* Move the YAML object model and writer into its own project so it can be shared by UIData.
The YAML stuff was exclusive to LottieData before. But now I want to use Yaml for dumping WinCompData trees, thus this refactoring.
* Fix the licensing header.
Alexandre Zollinger Chohfi
aborziak-ms
Simeon
Nishitha Burman
Simeon
Marcel Wagner
plaiMS
Phyllis Lai