Platform views that extend Control without overriding MeasureOverride collapse to zero size when HorizontalAlignment is not Stretch

[pardont]

Several platform views (SKCanvasViewControl, SKGLViewControl, PlatformGraphicsView, ProgressRingVisual) extend Avalonia.Controls.Control directly without overriding MeasureOverride. The base Control.MeasureOverride() returns default(Size), i.e. (0, 0).

This is not a problem when the MAUI virtual view uses the default HorizontalOptions="Fill" / VerticalOptions="Fill", because LayoutAlignment.Fill maps to HorizontalAlignment.Stretch, and Avalonia's ArrangeCore gives a stretched control the full parent-allocated space regardless of DesiredSize.

However, when the MAUI view sets HorizontalOptions="Start" (or Center, End), the handler maps it to HorizontalAlignment.Left (or Center, Right). In this case Avalonia's ArrangeCore clamps the final render size to DesiredSize — which is (0, 0). The control collapses to zero width/height, its Bounds become empty, and Render() returns early without drawing anything.

On the WinUI backend this does not occur because the WinUI handler for SKCanvasView does not limit the arranged size based on DesiredSize in the same way.

Affected controls

Control	File
SKCanvasViewControl	src/Avalonia.Controls.Maui.SkiaSharp.Views/Controls/SKCanvasViewControl.cs
SKGLViewControl	src/Avalonia.Controls.Maui.SkiaSharp.Views/Controls/SKGLViewControl.cs
PlatformGraphicsView	src/Avalonia.Controls.Maui/Platform/PlatformGraphicsView.cs
ProgressRingVisual	(similar pattern)

Note: GifImage in the same codebase does override MeasureOverride, so it is unaffected.

Reproduction

1. Create a custom control extending SKCanvasView that overrides MeasureOverride to return a non-zero size.
2. Place it in a layout with HorizontalOptions="Start".
3. Run on the Avalonia backend — the control is invisible.
4. Run on the WinUI backend — the control renders correctly.

Minimal XAML:

<sk:SKButton Text="Primary button"
             HorizontalOptions="Start"
             ButtonColor="#512BD4"
             TextColor="White"
             HeightRequest="48" />

Root cause

In ViewHandler.GetDesiredSize(), the handler calls platformView.Measure(constraint) and reads platformView.DesiredSize. Since these controls return (0, 0) from MeasureOverride, the Avalonia layout system considers their desired size to be zero.

When ViewHandler.PlatformArrange() later calls platformView.Arrange(rect), Avalonia's ArrangeCore applies the alignment:

// Simplified from Avalonia's ArrangeCore
var size = HorizontalAlignment == Stretch
    ? finalSize
    : DesiredSize; // ← (0, 0) for these controls

This shrinks the render bounds to zero, causing Render() to early-return.

Suggested fix

Override MeasureOverride in each affected control to return the available size:

protected override Size MeasureOverride(Size availableSize)
{
    return availableSize;
}

This is safe because MAUI's layout system already positions and sizes children through CrossPlatformMeasure / CrossPlatformArrange / PlatformArrange with explicit bounds. The Avalonia alignment is essentially redundant for MAUI-managed views — the platform view just needs to fill whatever frame MAUI allocates.

Workaround (consumer-side)

As a workaround without modifying this library, the control author can force the platform view to Stretch alignment in OnHandlerChanged:

protected override void OnHandlerChanged()
{
    base.OnHandlerChanged();
    if (Handler?.PlatformView is Avalonia.Controls.Control ctrl)
    {
        ctrl.HorizontalAlignment = Avalonia.Layout.HorizontalAlignment.Stretch;
        ctrl.VerticalAlignment = Avalonia.Layout.VerticalAlignment.Stretch;
    }
}

This works because MAUI's PlatformArrange supplies the exact frame, and Stretch prevents ArrangeCore from shrinking it.

Environment

• Avalonia.Controls.Maui: current main (90bcad8)
• Avalonia: 12.0.0-rc1
• SkiaSharp: 3.119.4-preview.1.1
• OS: Windows 10 / Debian 11
• Reproducible on: Avalonia desktop backend only (WinUI backend unaffected)

[drasticactions]

WinUI backend unaffected

I'm not sure what you're talking about here, there is no WinUI integration yet. This is just .NET MAUI running on WinUI normally.

[drasticactions]

@pardont Can you create a sample showing this?

[pardont]

Avalonia.Playground.zip

@drasticactions Attached is a minimal reproduction project: Avalonia.Playground.zip

In MainPage, Case 3 is the key point. UserCustomSKCanvasView subclasses SKCanvasView and overrides the MAUI-level VisualElement.MeasureOverride to return (100, 100), but is not display.

[drasticactions]

@pardont I apologize, I need to make sure I understand your issue, because the text in your example and what your saying here isn't aligned.

In your example text, it says

Expected: Cases 1, 2, 3 should all render colored rectangles.
Actual (Avalonia backend): Case 1 and 3 render. Case 2 collapses to zero because MeasureOverride returns (0,0).
Actual (WinUl backend): All cases render correctly.

But the actual issue is the when using the Avalonia backend, "Case 3" (which is the custom control with the MeasureOverride) doesn't render, where it does in the other platforms.

This is Avalonia

These are native.

[pardont]

@drasticactions Yes, that's exactly the core of the issue.

As you summarized:

• In Case 3, the custom control explicitly overrides MeasureOverride at the MAUI level and returns (100, 100).
• When running on the Avalonia backend, this control does not render (collapses to zero size / becomes invisible).
• However, on other .NET MAUI backends (such as WinUI, Android, etc.), the same code renders correctly.

This indicates that the problem is not simply about the base MeasureOverride returning (0, 0). Even when the MAUI layer provides a clear non-zero measure result, the Avalonia backend's layout system still fails to handle it properly, causing the custom control to collapse.

The screenshot you attached accurately reflects this behavior. I hope this issue can be further investigated and fixed. Please let me know if you need any additional test cases or logs from my side.

[drasticactions]

That's fine, I just wanted to make sure since I was confused by the text in the repro and what you wrote. I think I understand the issue.