Added the Render surfaces and their XAML brushes. (Ported from CompositionProToolkit)

[ratishphilip]

Fixes #3442

PR Type

What kind of change does this PR introduce?

Feature

What is the current behavior?

CompositionProToolkit library provides five types of rendering surface interfaces.

• IRenderSurface - This interface acts as the base interface for interfaces which render to the ICompositionSurface. It mainly contains references to an ICompositionGenerator object and an ICompositionSurface object which are the core objects required for rendering any geometry or image onto a ICompositionSurface.
• IMaskSurface - This interface is used for rendering custom shaped geometries onto ICompositionSurface so that they can be useds as masks on Composition Visuals.
• IGaussianMaskSurface - This interface derives from IMaskSurface and is used for rendering custom shaped geometries onto ICompositionSurface so that they can be useds as masks on Composition Visuals. You can apply a Gaussian Blur to the mask.
• IGeometrySurface - This interface is used for rendering custom shaped geometries onto ICompositionSurface.
• IImageSurface - This interface is used for rendering images onto ICompositionSurface.
• IImageMaskSurface - This interface is used for creating a mask using the alpha values of the image pixels.

Here is the interface hierarchy

These render surfaces can be a useful addition to the WindowsCommunityToolkit.

What is the new behavior?

This PR achieves the following

• It ports the above RenderSurfaces to Windows Community Toolkit. These surfaces can be used at the visual layer to create custom shaped visuals.

• It introduces various Geometric shape classes

  • CanvasCircleGeometry
  • CanvasEllipseGeometry
  • CanvasRectangleGeometry
  • CanvasRoundedRectangleGeometry
  • CanvasSquircleGeometry
  • CanvasPathGeometry
  • CanvasCombinedGeometry

• It also introduces XAML equivalent of Win2d brushes

  • SolidColorCanvasBrush
  • LinearGradientCanvasBrush
  • RadialGradientCanvasBrush

• It also introduces the following XAML brushes

  • GeometrySurfaceBrush
  • GeometryMaskSurfaceBrush
  • ImageSurfaceBrush
  • ImageMaskSurfaceBrush

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] Tested code with current supported SDKs
• [x] Pull Request has been submitted to the documentation repository instructions. Link: #564
• [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
• [x] 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...
• [ N/A] 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)
• [x] Contains NO breaking changes

Other information

[michael-hawker]

Thanks @ratishphilip! Not sure if you saw but I had created a CanvasBrushBase in the past, so just want to make sure we can align and either upgrade the existing functionality or deprecate the old if they serve similar purposes. I haven't dug fully into the PR yet, but I do want to make sure we've got things aligned and have a clear option for devs to pick the right choice if they need to create their own brushes.

There's also the PipelineBuilder sources and IPipelineEffect which are the hooks into Sergio's Pipeline Brushes, (and XAML Extensions). So it'd be cool if we could hook these new sources and effects into that ecosystem as well to be able to leverage the best of both worlds vs. having two independent ecosystems. Thoughts?

FYI @Sergio0694 would love your expertise on and assistance on possibility of integration here for all this goodness.

[ratishphilip]

Hi @michael-hawker , thanks for your comments.

Yes I had seen the CanvasBrushBase class, but it was not aligning to the requirements of the RenderSurface brushes. My primary goal was to define a class that would make it easier to declare Win2d brushes in XAML to serve mainly as an input to the brushes deriving from RenderSurfaceBrushBase.

WinUI already has SolidColorBrush, LinearGradientBrush and RadialGradient brushes which can be used by by the dev community and therefore do not need a port of Win2d brushes to a brush deriving from XamlCompositionBrushBase. I would recommend deprecating the CanvasBrushBase and RadialGradientBrush (defined under Media).

Yes, even I am eagerly waiting to hear @Sergio0694's comments on how to move ahead with integrating these brushes to PipelineBrush.

[michael-hawker]

Waiting for @Sergio0694 to return and provide some insights here. Since we're wrapping up 7.1 now, moving this to next milestone. @ratishphilip hope you don't mind?

[ratishphilip]

@michael-hawker that should be fine. Hopefully I can finish off documentation by then. 😀

[ratishphilip]

@michael-hawker that should be fine. Hopefully I can finish off documentation by then. 😀

@michael-hawker @Sergio0694 I have completed and uploaded the documentation. 😅 The PR can be found here.

[ratishphilip]

@michael-hawker @Sergio0694 Any updates on this PR?

[michael-hawker]

Hey @ratishphilip, sorry for silence here. 8.0 is a long cycle as we've been revamping our whole infrastructure of how we build the toolkit to support UWP and WinUI 3, see 2022 plans here.

I've also been waiting for @Sergio0694 to help instruct us how to integrate this into the Pipeline brushes somehow, but I know he's been pretty busy with the MVVM Toolkit work he's been doing as well.

In the meantime we'll be launching Labs soon, which will be the new entry point for things and allow us to better test this across UWP and WinUI 3 as well as write documentation/samples alongside it much easier. That could be a good place to at least unblock moving forward with this. (That's part of the reason why we're creating Labs too, so we don't get stuck in PR limbos like this.)

I'll be giving a talk about Labs as well at the .NET Foundation Summit.