WindowsCommunityToolkit
WindowsCommunityToolkit copied to clipboard
A animation helper that morphs between two controls
Feature #4323
A new animation helper that morphs between two controls was added in this PR and an example for it.
PR Type
What kind of change does this PR introduce?
- Feature
PR Checklist
Please check if your PR fulfills the following requirements:
- [x] Tested code with current supported SDKs
- [x] New component
- [ ] Pull Request has been submitted to the documentation repository instructions. Link:
- [ ] Added description of major feature to project description for NuGet package (4000 total character limit, so don't push entire description over that)
- [ ] If control, added to Visual Studio Design project
- [x] Sample in sample app has been added / updated (for bug fixes / features)
- [x] Icon has been created (if new sample) following the Thumbnail Style Guide and templates
- [ ] New major technical changes in the toolkit have or will be added to the Wiki e.g. build changes, source generators, testing infrastructure, sample creation changes, etc...
- [ ] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [x] Header has been added to all new source files (run build/UpdateHeaders.bat)
- [ ] Contains NO breaking changes
Other information
The document is not ready.
Thanks HHChaos for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request ๐
๐๐๐
This PR has been marked as "needs attention ๐" and awaiting a response from the team.
Sharing some thoughts I had on if we can expose XAML helpers for this as well:
<Page.Resources>
<ani:TransitionHelper x:Key="MyTransitionHelper">
<ani:AnimationConfig Id="background" Properties="Scale"/>
<ani:AnimationConfig Id="image" Properties="Scale"/>
<ani:AnimationConfig Id="guide"/>
<ani:AnimationConfig Id="name" Properties="ScaleY"/> <!-- If use flag enum then should be able to combine like "ScaleX,ScaleY" -->
<ani:AnimationConfig Id="desc"/>
</ani:TransitionHelper>
</Page.Resources>
<!-- Existing Sample Code -->
<Button x:Name="MaxToMinButton">
<interactivity:Interaction.Behaviors>
<interactions:EventTriggerBehavior EventName="Click">
<behaviors:StartTransitionAction Transition="{StaticResource MyTransitionHelper}" Source="{Binding ElementName=ThirdControl}" Target="{Binding ElementName=FirstControl}"/>
</interactions:EventTriggerBehavior>
</interactivity:Interaction.Behaviors>
</Button>
Will have to dig into code more and think if we can simplify a bit further... ๐
Super excited to see how this feature can be used! Super cool. Going to mark as draft for now as we continue to explore and optimize.
@michael-hawker Do I need to add separate samples for StartTransitionAction
and ReverseTransitionAction
? Actually I think this sample seems to be enough.
@michael-hawker Do I need to add separate samples for
StartTransitionAction
andReverseTransitionAction
? Actually I think this sample seems to be enough.
@HHChaos It would be useful to first-timers if we had a simple example alongside the more complex one.
@michael-hawker Do I need to add separate samples for
StartTransitionAction
andReverseTransitionAction
? Actually I think this sample seems to be enough.@HHChaos It would be useful to first-timers if we had a simple example alongside the more complex one.
I have added a new example for them.
Looks pretty good, had a few cleanup suggestions and questions.
One more general question to consider. While using Composition by default is obviously a good choice, there may be scenarios where using the XAML layer is required. Since the AnimationBuilder APIs make this easy, should we expose an option to use either Composition or XAML layer?
I can't think of such a scenario, and based on performance considerations, I think it's ok now.๐ค
I can't think of such a scenario, and based on performance considerations, I think it's ok now.๐ค
I was more or less thinking ahead to an Uno port where Composition isn't fully available, but we can leave it as is, and let Uno complete their Composition API polyfills to make this work cross-platform.
If everything under the hood is just using the Toolkit Animation APIs, it probably wouldn't hurt to put a property for the Animation layer on the TransitionHelper then. @Sergio0694 thoughts/concerns with that? Would be handy to get you on the PR review for this too. ๐
Hey @HHChaos got to play with this a little more today. This is super cool. ๐ฆโค
Probably something I'm going to suggest we bring into Labs (see #4487) to get into folks hands sooner as 8.0 is a ways away. (Though we'll have to figure out some dependency things for that maybe.)
Anyway, I did notice a couple of minor things from a sample/interaction perspective:
- In
Light
mode (at least on Windows 10) you can't really see the border, so it's hard to know that's animating as well:
Compared to dark mode:
- I'm noticing the tiniest of 'flicker' when the animation starts. I hypothesize this is from the switch in visibilities between the source and the target elements at the start of the animation.
i.e. I think we need to ensure that the element which is currently invisible becomes visible first before the element which is visible becomes collapsed (regardless of the direction of the animation)
I'm not entirely sure if this is based on the visibility toggle ordering or something based with the Opacity manipulation that is occurring also?
Thoughts?
Hey @HHChaos got to play with this a little more today. This is super cool. ๐ฆโค
Probably something I'm going to suggest we bring into Labs (see #4487) to get into folks hands sooner as 8.0 is a ways away. (Though we'll have to figure out some dependency things for that maybe.)
Anyway, I did notice a couple of minor things from a sample/interaction perspective:
- In
Light
mode (at least on Windows 10) you can't really see the border, so it's hard to know that's animating as well:
Compared to dark mode:
- I'm noticing the tiniest of 'flicker' when the animation starts. I hypothesize this is from the switch in visibilities between the source and the target elements at the start of the animation.
i.e. I think we need to ensure that the element which is currently invisible becomes visible first before the element which is visible becomes collapsed (regardless of the direction of the animation)
I'm not entirely sure if this is based on the visibility toggle ordering or something based with the Opacity manipulation that is occurring also?
Thoughts?
Hi @michael-hawker ,
For 1st issue, this seems to be a problem with AttachedCardShadow
? I can't reproduce this problem in Win11. Anyway, I removed the AttachedCardShadow
, and changed the background to fix it.
For 2nd issue, it is actually a complex issue, since our opacity animation doesn't change the order of elements on the Z axis, so it's not just a visible/invisible state toggle, transition animations may also be affected by elements with higher Z-Index, I've noticed this problem before, but I didn't find a perfect solution. I've added a TransitionMode
to help mitigate this issue, you can check if that works.
@HHChaos ah, you can't apply an AttachedShadow
directly to a border, see the example here:
https://github.com/CommunityToolkit/WindowsCommunityToolkit/blob/2d9041626d9dd7c90be94558b166e378ac2eb845/Microsoft.Toolkit.Uwp.SampleApp/SamplePages/Shadows/AttachedShadowWin2DXaml.bind#L44-L61
The behavior is a bit different between Windows 10 and Windows 11 as Windows 11 has a different default clipping behavior I believe, so it may work slightly better. Anyway, solid background will seem fine.
For 2) the transition seems a lot smoother now with the image! ๐
Saw there was another sample for the StartTransitionAction. I spammed the buttons a bit and rarely was able to see a case where it jumped to the finished start/end state (saw it in both directions) without the animation in between. Not sure if a rare timing/threading issue or something else, and not sure if due to transition helpers, behaviors, or animation API/usage itself. Just wanted to call it out though, probably not a big issue, but something we should track. I couldn't see any consistent repro to it. Saw it maybe only once out of every 20-30 transitions? FYI @Sergio0694 in case he has any tips for debugging such things.
Was also wondering @HHChaos if a developer used this on items in a DataTemplate, does that work? I'm imagining a scenario where they have a list of items, and then have a popup/overlay type dialog (that's also contained on their page - as I assume that's a requirement for this API?) that they want to display and how the item coming from? We're close to having labs in a good state to at least start propping up some experiments privately, so we can wait to try this out over there where it may be easier to craft a sample and play with directly, though have to think about how the animation dependency works in Labs. ๐
Hi @d2dyno1 and @michael-hawker, I removed TransitionMode
because I thought it could be confusing for developers. I modified the transparency animation and I believe it will better solve the flicker issue mentioned by Michael.
@HHChaos we want to move this over to Labs. Is that something you want to learn how to do, or want us to help assist with the initial migration (we can still credit the commit to your account)? Let us know, in either case, @niels9001 and I can help out here.
Thanks @michael-hawker @niels9001 for help! It would be best if you could help with the initial migration.
@HHChaos thanks for continuing to update this PR. ๐ฆโค As discussed previously, I've moved this PR to Labs. The new PR is here: https://github.com/CommunityToolkit/Labs-Windows/pull/354
Get better soon, we're all wishing you well.