Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
What's the philosophy behind the changes of XAML Composition Interop Behavior? #145
As always, we hope to animation the UIElement, or Visual's offset relatively, which means that I don't care where it is in its parent. For example, while I want to move the border's offset.x by value of 100, I can achieve this by:
To illustrate this:
Note that in this case, the border is in a
The first method always works. Though it's using Storyboard and it's kind of weighty.
The second method works in November update since the visual returned by calling
But now in Anniversary update:
That means the visual I get from XAML should has a right offset and size which correspond to XAML. And when you make changes in XAML, the visual properties will changes too.
As a result, if I continue to code this to animation the border's offset.x to value of 100:
The final position of border is (0,100) in Grid's coordinate, which is :
To achieve the original need, I should change the animation to this:
It kind of works, and however, if you continue to toggle the animation, the border's offset.x will be continued to set to the new value since the
In addition, if you try to re-size the window after the animation being started, the border's offset will be reset to the original value and can't stay on the final value.
The situation talking above is NOT the worse part.
That means the visual I get from UIElement should have a actual size instead of (0,0) in November update. However, the value in Visual is not synced with XAML value. In
The non-sync value updating process puzzles me though.
I want to animate the rotation of Ellipse by its center, and then I should set it's
As a workaround, I should use XAML size instead of Visual size to set the center point:
In conclusion, what sense does this Interop Behavior change makes?
Not an answer to all of your above, but considering this:
You don't particularly need to care what the size if you take a more efficient expression animation route that will automatically handle size changes for you
I personally manage it's lifecycle through a behaviour which creates the animation on
(The docs read like you should be able to do it with a Vector2 targeting Centerpoint.xy, but that just does not work.)
Of course, that only works when size actually updates. I've had strange instances where the visual size _never updates to match the ActualHeight/ActualWidth/RenderSize, but that's definitely an exception rather than the rule_
I want to answer your overall question about the change and the philosophy behind it. The reason for the sharing of the Offset property was to allow implicit animations to run as a result of Layout changes - this would allow you to run an input driven animation as the user resizes the window. Implicit animations were introduced in the Anniversary edition update. The downside is that this means using the Offset property becomes much trickier than in 10586 as you now need to pay attention to what XAML layout is doing or create your Offset on a canvas or panel layout doesn't touch. We've written this up here on MSDN
That said, this is not a closed book on how we want to do things, especially as more and more users are adopting the API and we're completely open to listening to any alternative approaches or suggestions here for future releases.
@sernaj So is that possible to separately return a (child) Visual for us to do any additive manipulations as build 10586 did before?
And I wonder is there any way to contribute localization for documents on MSDN since many newly added docs about Windows 10 development are in English.
Personally I think it would have been nicer to have two separate properties, the current Offset, and then RenderOffset (because I can't think of a good name and really it should be called Offset, and the current Offset should be called Position), which works similarly to how a RenderTransform would / is additive to the Offset property. (Presumably how Offset used to work?). Then you could both care / not care about XAML depending on what you want to do. Though I'm guessing most of us want to not care.
Granted, wrapping your object in a Border / Canvas also works fine, but especially with things like DataTemplates, it's a lot of useless extra inside the VisualTree that takes CPU to create and manage and render, and additional memory.
I wanted to circle back to this issue and update everyone that we have a new fix for Offset sharing/Stomping in the Creator's update:
Let me know if you have any feedback on the new property insertion.
@JohnnyWestlake @JuniperPhoton we're looking to keep the Visual itself fairly lightweight and agnostic to the XAML layout tick. We're discovering most scenarios that encounter layout stomping use Offset animations happen on Visuals obtained via ElementCompositionPreview.GetElementVisual and are backing a UIElement. If you're building custom comp content via SetChildVisual you're never stomped. So instead of adding a second Offset or Translation to the Visual (where it would be used in some scenarios only) we're looking at reconciling this directly on UIElement. So, for example, you may see an additional property there in future that also works with Win.UI.Comp animations. This takes us back to title of the topic, we're seeing the future of interop as pushing Composition goodness scenarios up to the Framework in places like UIElement where it's most accessible, while keeping the Visual Layer itself fairly lean. This is one of the reasons we landed on the current PropertySet fix, so that he extra property was used when needed so that long term when we push Comp goodness up we don't have to deprecate properties on the Visual (and can keep it lean.) BTW we will be pulling in the community for feedback on the next round of interop work, so stay tuned for that.