microsoft / microsoft-ui-xaml

WinUI: a modern UI framework with a rich set of controls and styles to build dynamic and high-performing Windows applications.
MIT License
6.38k stars 683 forks source link

Proposal: Add access to Compositor for XamlIslands scenario #756

Open kmelmon opened 5 years ago

kmelmon commented 5 years ago

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

Capability Priority
This proposal will allow developers to access the Compositor when the app is running in a XamlIsland Must

Important Notes

Open Questions

eklipse2k8 commented 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.

jesbis commented 5 years ago

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.