Update taffy requirement from 0.1.0 to 0.2.1

[dependabot]

Updates the requirements on taffy to permit the latest version.

Changelog

Sourced from taffy's changelog.

0.2.1

Fixes

• In case of conflicts, min_size now overrides max_size which overrides size (#261). This is the behaviour specified in the CSS specification, and was also the behaviour in Taffy v0.1.0, but a regression was introduced in Taffy v0.2.0.
• taffy::compute_layout has been made public allowing Taffy to be used with custom storage (#263)

0.2.0

New features

Flexbox "gap" and AlignContent::SpaceEvenly

The gap property is now supported on flex containers. This can make it much easier to create even spacing or "gutters" between nodes.

Additionally we have a SpaceEvenly variant to the AlignContent enum to support evenly spaced justification in the cross axis (equivalent to align-content: space-evenly in CSS)

Debug module and cargo feature

Two debugging features have been added:

• taffy::debug::print_tree(&Taffy, root) - This will print a debug representation of the computed layout of an entire node tree (starting at root), which can be useful for debugging layouts.
• A cargo feature debug. This enabled debug logging of the layout computation process itself (this is probably mainly useful for those working taffy itself).

Performance improvements

A number of performance improvements have landed since taffy 0.1:

• Firstly, our custom taffy::forest storage implementation was ripped out and replaced with a much simpler implementation using the slotmap crate. This led to performance increases of up to 90%.
• Secondly, the caching implementation was improved by upping the number of cache slots from 2 to 4 and tweaking how computed results are allocated to chache slots to better match the actual usage patterns of the flexbox layout algorithm. This had a particularly dramatic effect on deep hierachies (which often involve recomputing the same results repeatedly), fixing the exponential blowup that was previously exhibited on these trees and improving performance by over 1000x in some cases!

Benchmarks vs. Taffy 0.1

Benchmark	Taffy 0.1	Taffy 0.2	% change (0.1 -> 0.2)
wide/1_000 nodes (2-level hierarchy)	3.5458 µs	4.3571 µs	+23.333%
wide/10_000 nodes (2-level hierarchy)	36.418 µs	42.967 µs	+17.357%
wide/100_000 nodes (2-level hierarchy)	1.8275 ms	3.9096 ms	+112.26%
deep/4000 nodes (12-level hierarchy))	5.1845 s	15.318 µs	-100.000%
deep/10_000 nodes (14-level hierarchy)	75.978 s	40.315 µs	-100.000%
deep/100_000 nodes (17-level hierarchy)	-	2.7644 ms	-
deep/1_000_000 nodes (20-level hierarchy)	-	1.2130 s	-

(note that the table above contains multiple different units (milliseconds vs. microseconds vs. nanoseconds))

As you can see, we have actually regressed slightly in the "wide" benchmarks (where all nodes are siblings of a single parent node). Although it should be noted our results in these benchmarks are still very fast, especially on the 10,000 node benchmark which we consider to be the most realistic size where the result is measured in microseconds.

However, in the "deep" benchmarks we see dramatic improvements. The previous version of Taffy suffered from exponential blowup in the case of deeply nested hierachies. This has resulted in somewhat silly improvements like the 10,000 node (14-level) hierachy where Taffy 0.2 is a full 1 million times faster than Taffy 0.1. We've also included results with larger numbers of nodes (although you're unlikely to need that many) to demonstrate that this scalability continues up to even deeper levels of nesting.

Benchmarks vs. Yoga

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[james7132]

Closing in favor of #6743.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.