Problem with bringing items in to view in the Items Repeater.

[igorstefus]

There seems to be a problem with bring in to view calls for repeater items. This issue is related to repeater virtualization where item needs to be created and scrollbar position needs to be calculated before item can be brought in to view.

For this to work GetOrCreateElement was made public but usage of it is not relay user friendly and can cause some issues.
After call to GetOrCreateElement is made user will get new item but calling BringInToView will result in empty repeater viewport if user does not wait for layout pass to be finished.
This not only mean user is not quite sure when can BringInToView be called but also additional items can be added to repeaters source collection before layout pass is over and this can also lead to empty viewport.

So only option user has is to force layout update after GetOrCreateElement to make sure all is ready for BringInToView call.
I wonder if we can make BringInToView safer feature to use as I imagine bringing things in to view in the repeater is one of things users will need.

To demonstrate this I created small repository: https://github.com/igorstefus/AvaloniaRepeaterProblem/tree/master/RepeaterProblem

[grokys]

This seems to be the way ItemsRepeater was designed to work. From the MS docs:

https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/items-repeater#bringing-an-element-into-view

Bringing a virtualized element into view involves the following:

1. Realize a UIElement for an item
2. Run the layout to ensure the element has a valid position
3. Initiate a request to bring the realized element into view

WPF has the UpdateLayout method which makes it a bit less ugly, maybe we should just add UpdateLayout to ItemsRepeater?

[grokys]

UWP has the UpdateLayout method on UIElement: https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.updatelayout?view=winrt-19041 but the reason we dont have it is (from the UWP docs):

Layout updates can be forced by app code rather than relying on the built-in layout system behavior by using the UpdateLayout method. However, that is not generally recommended. It is usually unnecessary and can cause poor performance if overused.

Which is also true for Avalonia, so we make it a bit more difficult by having to get the layout manager etc. but given that doing a manual layout is necessary for ItemsRepeater we could expose UpdateLayout on ItemsRepeater.

[igorstefus]

Yeah that make sense. At least user doesn't need to hunt for LayoutManager. If noting more to make it more streamlined :)