Android shadow performance

[albyrock87]

Description of Change

Apparently DrawShadow has an absurd impact on the performance.
Here's a speedscope from our app sorted by self time descending, also look at total time %!!!

This PR:

• moves the shadow computation to android level with an improved algorithm
  • uses Glide's LruBitmapPool to reduce the memory pressure on Java
  • prepares Paint only when shadow changes
• when we know we're going to render a solid shape we can use Canvas API to speedup the shadow rendering performance by a lot
• removes unneeded saveLayer call from platform interop: it's a very expensive operation done for no reasons here
• fixes shadow rendering on Android which was still broken (despite Shadows not rendering as expected on Android and iOS #24414) under some conditions (like negative offsets)

I tried as much as possible to not break signatures but given Java to C# bindings are automatically generated, there was no way completely avoid touching public APIs.

Here I've executed the testing host app with return new ShadowBenchmark(); as main page and scrolling the CV for ~30 seconds.

Before

DrawShadow takes 24%.

before.speedscope.json

After

DrawShadow is gone.

after.speedscope.json

Important notes about the benchmark

Now you may suppose that we've simply hidden the cost of drawShadow from the profiler.
That is in part true, this is why I've also measured this on a real app by looking at the root drawChild performance.
You can clearly see a 40% improvement (833ms vs 523ms).

Issues Fixed

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/rebase

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[AmrAlSayed0]

I'm late to the party but an attempt to improve shadow's performance was made before here #10523. Moving the code to the Java side might help but I think what would benefit the most is a shadow cache. All views that have the same size and the same shadow properties (very common scenario in CollectionView items for example) should use the same bitmap. This will eliminate a huge number of calls including C# to Java ones. There is an implementation of the shadow cache in the PR.

[albyrock87]

@AmrAlSayed0 thanks for sharing, I'll check it out.
This is still a very early WIP.
I also intend using Glide's bitmap pool for this, which should improve the performance by avoiding continuous allocations of the bitmaps.

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jonathanpeppers]

This calls the Context property three times in a row. This will call into Java each time, doing the bookkeeping to lookup the C# object.

Can you store Context in a local to reuse it?

[albyrock87]

Good catch!

[jonathanpeppers]

Do you have any details why to use getApplicationContext?

It looks like the ShadowBitmapPool is used once per PlatformWrapperView, which would have the same lifetime as an activity anyway?

If we used a single ShadowBitmapPool for the entire application, seems like getApplicationContext would be appropriate in that case.

[albyrock87]

See comment below: we use only one pool.

[jonathanpeppers]

So, we use 1 pool per PlatformWrapperView.

Can we use 1 pool for the entire application? That would allow many views to share the pool.

[albyrock87]

Actually that static method returns one pool for the entire application, so exactly what you're asking :)

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[AmrAlSayed0]

Correct me if I'm wrong but what this is doing is using a pool not a cache. Which means that no 2 views will ever use the same bitmap, it's just that that bitmaps will be reused and recycled instead of being created each time it's needed to better conserve memory.

I was thinking of a cache for when, for example, 200 items in a CollectionView request the same exact bitmap cuz they have MeasureFirstItem set (hence same size) and have the same template (hence the same shadow properties) and the same bitmap can be set for both.

I know this PR is already doing too much so this maybe an optimization for a later time ..

[albyrock87]

@AmrAlSayed0 there's a small "cache" at the view's level which reuses the bitmap content when not shadowInvalidated.

But from my analysis, this is probably ineffective as every time something changes on the descendants (requestLayout) the shadow is being invalidated.

The reason for this invalidation is that the shadow is based on content pixels.
For example, you may have a collection view containing simple Labels with a shadow.
Now every label may have the same height, but the shadow will be different considering the text is different.

This is really a pain as Android doesn't offer a better way to draw a shadow based on the content.

What I've done here though, is detecting if you have a shadow applied to a solid rectangle, or a solid Border.
If that's the case the shadow will be drawn based on the shape directly on the rendering Canvas: this is super fast and we don't have to worry about bitmaps at all.

Unfortunately there is an edge case not covered, so I'm discussing with the MAUI team what to do.

Thanks for your input on this!