Improve performance of MAUI handlers

[softlion]

MAUI handlers are an architecture choice that should impove performance over Xamarin renderers.
But the goal is only partially achieved.

MAUI handlers have removed the extra containers that were created, based on the success of the fast renderers on Android.

But MAUI handlers are also based on Mappers, to ease the customization of controls.
This last feature makes difficult for a handler to know when all the properties have been set/bound, so the control can start computing its size and its UI.

Instead, with the current way of things, when any mapper is called on a proprerty that changes its appearance, the control must redraw itself. Leading currently to one redraw per property in the mapper. Making the control very slow.

An improvement would be to have a method called on the handler after all the mappers were initially set, and after all the bindings were resolved (that can be 2 methods).

What do you think ?

[hartez]

Instead, with the current way of things, when any mapper is called on a proprerty that changes its appearance, the control must redraw itself. Leading currently to one redraw per property in the mapper.

That's not how appearance/layout changes work.

When a mapper modifies a property which affects appearance/layout, the control's native invalidation mechanism is invoked (e.g., setNeedsLayout(), requestLayout(), InvalidateMeasure()). This marks the control (and possibly other parts of the hierarchy) as needing to be updated during the next native layout/drawing pass.

If a new control is initialized and a dozen properties are set on it all at once, each one of those property changes will trigger an invalidation. But that simply marks it as needing to be updated during the next pass; the actual visual updates all happen during that single pass. So a single property update on a single control means one layout pass. 10 property updates on 10 different controls still results in one layout pass.

Making the control very slow.

[citation needed]

Do you have any specific benchmarks of controls working slowly? We definitely want to know if anyone is experiencing particular performance issues so we can delve into them.

[softlion]

Yes i do have a native custom control which performs very well under Xamarin and becomes very slow under Maui.

This custom control prepares its internal resources in a background thread before the draw pass (and not the layout pass), to avoid blocking too long the drawing thread.

It has some few properties whose change discard and restart the preparation of its internal resources.
I have found a way to lower the number of calls to the preparation to 2 by using the OnHandlerChanged event. Why not 1 ? Because OnHandlerChanged is called after all the direct xaml properties of the control have been set, but before the complex properties defined by some xaml inside the control's xaml tag have been set.

Anyway, even with only 2 preparations, when used in a CollectionView, the scrolling becomes heavily jumpy. On both android and iOS, simulator and device.
The same xaml code with Xamarin performs very well with a smooth scrolling. So something else is wrong somewhere in maui's CollectionView.

[hartez]

So something else is wrong somewhere in maui's CollectionView.

That's certainly possible; we've had a few reports of performance issues with CollectionView.

[softlion]

It's not only the CollectionView. I do see my native control draw it's content "late" instead of nearly instantly. I would say between 50ms and 200ms after it is displayed. Instead of <10ms. Especially on the Android simulator which runs very fast with a fast high end CPU.

[softlion]

This one should not have been closed.
#8012

[softlion]

There is finally a workaround: embed your CollectionView inside a ContentView ... !!!

[Kanat9494]

please, if it is not difficult, give an example of this