Open kmelmon opened 5 years ago
On iOS the equivalent compositor functionality is exposed on every UIView through the layer property. I feel like needing a static method to pull out the compositor is a bit unnatural.
I think in a scenario like this, it's weird, because the button isn't actually bound to any parent layer. So one idea could be the Composition() property should be a nullptr.
Button button;
button.Composition().Origin({0, 0, 0});
Then in a hypothetical method OnLayoutRequested() it would be available for layout.
void MyGrid::OnLayoutRequested(...) noexcept
{
button.Composition().Origin({0, 0, 0});
}
However, there's a lot of model state that could be configured along with the Element model. It might be weird to apply an origin to something that's not part of the view tree, it seems perfectly valid to assign any implicit animations, and brushes.
Every Xaml UIElement has (or at least can have) a CompositionObject backing it, and you can get the compositor instance from any CompostionObject via CO.Compositor.
Maybe it's time to deprecate ECP::GetElementVisual and add:
Microsoft.UI.Composition.Visual UIElement.Visual { get; }
for WinUI 3?
That would also be similar to the mentioned UIView.layer pattern.
Proposal: Add access to Compositor for XamlIslands
Summary
Currently there are 2 ways to access the Compositor from a XAML app: 1) Window::Current.Compositor 2) ElementCompositionPreview::GetElementVisual.Compositor The Window mechanism sort of works but we want to deprecate Window as it is mostly broken in islands scenarios (most of the properties don't make sense for an island). The ECP mechanism only works if you have access to a UIElement, and we also want to deprecate the ECP API.
This proposal is to add a way to access the Compositor from some central place in XAML. Not sure where yet.
Rationale
Scope
Important Notes
Open Questions