How can I add a lot of data to the UI without lag?

[kyuranger]

I'm currently working on an OnScreenKeyboard Input Method, and I need to display the words that the input method matches. To do this, I've created a VirtualizingWrapPanel to solve the problem of too many elements in the UI.

Although VirtualizingWrapPanel can solve the problem of lag caused by rendering in non-visual positions, lag will still occur if a large number of elements are added at the same time in the visible position.

Now I can only use a strange solution like the following:

protected override async void OnLoaded(RoutedEventArgs e)
{
    for (int i = 0; i <= 1000; i++)
    {
        _ViewModel.CandidatesOC.Add(i.toString());
        await Task.Delay(1);
    }
}

As shown in the video below, although it can solve this problem to a certain extent, it still requires a long adding process, and the user experience is very bad. I would like to know if there is any way to solve this problem, thank you.

[stevemonaco]

You should chunk more than 1 item per delay. I suspect 10-100 is fine with how simple your UI elements are. This will speed things up a lot and may be "good enough".

Besides that, you can do much better if you can either: 1. create a design with fixed item width. 2. separate or count results by number of glyphs. The last line with single glyph should break to the next line if there's extra space. The first two glyph entry will always start on a new line and leftmost. This makes the calculation much easier as you can use fixed width sizing (even if it's per-group: 1, 2, 3 characters, etc). Fixed sizing means you can use multiplication to determine height and not measure every element. This is effectively instantaneous at the cost of some flexibility.

If you can do that, then you throw your virtualization away. Create ILogicalScrollable, custom draw your text (with FormattedText or glyph run), and do hit detection / hover yourself. See https://github.com/wieslawsoltes/HexView/blob/main/HexView.Avalonia/Controls/HexViewControl.cs as an example of most of that. I'm not sure if caching the FormattedText / glyph run is necessary, but you could try that if you need the last bit of perf. See the following for drawing glyph runs:

Avalonia/samples/RenderDemo/Pages/GlyphRunPage.xaml.cs

Lines 56 to 80 in b92bb93

	public override void Render(DrawingContext context)
	{
	var c = (char)_rand.Next(65, 90);
	if (_fontSize + _direction > 200)
	{
	_direction = -10;
	}
	if (_fontSize + _direction < 20)
	{
	_direction = 10;
	}
	_fontSize += _direction;
	_glyphIndices[0] = _glyphTypeface.GetGlyph(c);
	_characters[0] = c;
	var glyphRun = new GlyphRun(_glyphTypeface, _fontSize, _characters, _glyphIndices);
	context.DrawGlyphRun(Brushes.Black, glyphRun);
	}
	}

[kyuranger]

Unfortunately, my project form is variable and cannot be fixed in width or length.

[stevemonaco]

This will forever be slow then. What you've shown so far isn't special enough to require variable width elements.

[LaurentInSeattle]

IF _ViewModel.CandidatesOC is an ObservableCollection, this is somewhat "normal". The collection will fire events for each Add().
Adding all the stuff in a temp' list, then create a new ObservableCollection using the list as the CTOR parameter, this will bind only once and should solve the issue.

[thevortexcloud]

Also using a different collection type can help. EG ReactiveUI's sourcecache works pretty well (although you might need to change update modes). I have also had some success with doing a custom observable collection that allows for suspending change notifications/bulk adds.

[kyuranger]

I followed your advice and initialized the ObservableCollection directly using the new ObservableCollection(IEnumberable); method, which indeed resolved the initial load lag issue. However, my UI uses an infinite scroll to load more items in the waterfall layout. I tried using the ObservableCollection.AddRange method in DynamicData to load a batch of 50 items, the same as when initializing the ObservableCollection, but it still caused a lag of about 3-4 seconds. What could be causing this?

[kyuranger]

And the Task.Delay() will be unnecessary...

I really can't find any other way. I tried the ObservableCollection.AddRange method in DynamicData, but it doesn't seem to work, or I don't quite understand how to use it.

[kyuranger]

Also using a different collection type can help. EG ReactiveUI's sourcecache works pretty well (although you might need to change update modes). I have also had some success with doing a custom observable collection that allows for suspending change notifications/bulk adds.

I am not very familiar with ReactiveUI. In my current Avalonia programming, I mostly use CommunityToolkit.Mvvm and SqlSugar, and even DynamicData is rarely used.

[kyuranger]

Yes, creating and assigning a new collection in a case like this saves quite a bit since it's not large/expensive enough to warrant chunking.

Yes, it really works. But my UI uses an infinite scroll to load more items in the waterfall layout. I still have to solve the problem of adding batch data later.

[LaurentInSeattle]

AddRange will loop on the basic Add and will raise three events for each item added. Therefore for each add, there will be a measure, arrange, and virtualization pass. Same problem.
ObservableCollection (OC) works well for adding removing single items at a time. Looking at the short video, it is hard to tell whether on not you actually need an OC in your app. If all the stuff is Display Only, no adds, no remove, and just bulk updates, most likely not. Maintaining a good old plain list and raising "manually" a property changed event worked well for me in a vaguely similar situation. That was for WPF but OC is .Net not Avalonia.

[stevemonaco]

Layout/measure passes tend to be deferred, so this isn't exactly true unless they're continuing to delay after each add. Or their custom layout panel somehow always performs a relayout.

[lld1995]

Use ObservableCollectionExtended and SuspendNotifications when for add item,and then Dispose

[kyuranger]

Following @LaurentInSeattle 's answer, I suddenly remembered that I'd been using ObservableCollection in ItemSource bindings, without considering other data formats. Then, on a whim, I asked Grok (an AI model) if it had any suggestions for better data formats. Grok suggested using AvaloniaList, a data format developed by Avalonia that offers better performance than ObservableCollection and natively supports methods like AddRange. I tested it, and with AvaloniaList, adding 50 items in a batch didn't cause any noticeable lag (though there was still a lag of around 100ms), which I find acceptable.

[thevortexcloud]

Keep in mind using Avalonia list is couples your view models directly to Avalonia. It's also sort of an MVVM violation as well because of that.

[kyuranger]

Keep in mind using Avalonia list is couples your view models you directly to Avalonia. It's also sort of an MVVM violation as well because of that.

Why do you say that? I don't quite understand what you mean. Could you elaborate on that?

[thevortexcloud]

Since Avalonia list comes from Avalonia, that means your view model has to know about Avalonia to be able to use it for binding. Generally speaking, a view model should know nothing about the presentation system.

You should be able to take your entire view model and use it without Avalonia and in a completely different UI framework (EG WPF) without changing any code. Most people however are not that strict. I personally try to do it anyway though, since I never know where I will need to reuse the code in future.

[kyuranger]

I see what you mean. Thanks for the reminder.