Android drawable perf

[albyrock87]

Description of Change

Backgrounds are everywhere in our apps, so we must be fast when drawing android views, and Java -> C# is not.

This PR tries to do its best to completely move the logic into a java PlatformDrawable class.

Benchmarks (~50% improvements in mapping, ~60% improvement in rendering time)

I used #24414 as main page wrapped into a Shell component given it has a drawChild method which shows the cumulative draw time.

The results are impressive and will for sure make an impact!

24414-net10.json

24414-pr-final2.json

[jfversluis]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jsuarezruiz]

There are some related failing tests:

Differences between snapshots. Based on the failing tests, seems like not apply dynamic changes (like a dynamic binding for example. Could you review it? Let me know if can help with something.

[albyrock87]

@jsuarezruiz you can run AZP again.. though initially I had 80% perf improvement, but now with the last force push it's like 0%.. anyway I'm curious about UI tests failures.

So I must have done something wrong, or I must have missed some caching opportunity.
I'll try to look at this again tomorrow.

[albyrock87]

@jsuarezruiz I've pushed another commit, and this time the timing looks better but not what I wanted/expected.

There's only a 3ms performance gain.. now maybe this becomes much higher with a real world complex app, but I hoped to achieve something more.

Please run /azp

[albyrock87]

Wait, I found another issue.

[albyrock87]

@jsuarezruiz this is now ready, I've updated all the benchmarks in the description

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[albyrock87]

@jsuarezruiz @PureWeen the PR is now ready, I added a few commits with the fixes and updated screenshots, here's a summary:

• IShape can change even without changing instance (because Shape is a bindable property) so for performance reasons, I've introduced an internal IVersionedShape so that the MauiDrawable can still avoid some calls and retain the expected performance
• Screenshots are different because I finally fixed the bug where the default stroke color was black on Android (you can verify other platforms and you will see the border is transparent unless the developer specifies a color)
• Fixed gradients not working

[mattleibow]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/azp run

[PureWeen]

/azp run maui-pr-uitests, maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[sheiksyedm]

@albyrock87 After applying the last commit, a Shadow on a Border without an explicit background causes the shadow brush to visually fill the entire background, which leads to the uitest RadioButtonUpdateValueInsideBorder failure. You can reproduce the issue using the simple code provided below. Can you review this failure?

<Border StrokeShape="RoundRectangle 16"
                    StrokeThickness="1"
                    Padding="20,16"
                    Shadow="{Shadow Brush=Gray, Offset='4,4', Radius=12, Opacity=0.5}">
                <Label Text="Shadow Test"
                       FontSize="20"
                       FontAttributes="Bold"
                       HorizontalOptions="Center"/>

</Border>

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 31567

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 31567"

[albyrock87]

So it turns out that on main there was always a big mistake

maui/src/Core/AndroidNative/maui/src/main/java/com/microsoft/maui/PlatformInterop.java

Lines 510 to 518 in e6bb31a

	public static int getWindowBackgroundColor(Context context)
	{
	TypedValue value = new TypedValue();
	if (!context.getTheme().resolveAttribute(android.R.attr.windowBackground, value, true) && isColorType(value)) {
	return value.data;
	} else {
	return -1;
	}
	}

As you can see there is a ! in front of context.getTheme().resolveAttribute which is obviously wrong.
In my code this was correct, but I had another bug which I fixed in the last commit.

Correcting my bug though created a different behavior because the code on main has never worked 🐛

Given this never worked, I have completely removed the theme-related code which makes everything work fine and the code cleaner.

You can see the changes in my last commit.

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).