Performance issue when pointer move

[DmitryEvstakhov]

Mapsui Version
5.1.0-beta.1

Mapsui Platform
Avalonia

Device
Windows 11

We have a WPF project using Mapsui v4 that is being migrated to Avalonia using Mapsui v5.
We sometimes need to display several thousand objects (lines and polygons) on the map. The initial loading and rendering of objects is a bit slow, but that’s a minor issue.

The main problem occurs after all objects are fully rendered: when moving the mouse pointer over the map, there’s a constant call to GetFeatures, followed by re-rendering, which significantly slows down the entire application’s UI. No additional data is being loaded at this time, yet the UI still lags heavily.

We have several tool panels — some are positioned over the map (e.g., Panel_1 from the image), others are placed beside it (Panel_2).
When moving the mouse over Panel_1, the slowdown still occurs, but moving the cursor over Panel 2 does not cause lag. If there are ComboBoxes on the panels, attempting to select an item causes a delay — even when interacting with controls on Panel 2 (during which GetFeatures is still being called).

I understand that displaying a large number of objects affects performance. But it seems to me that once we’ve rendered something on the map and are neither dragging the map itself nor loading new data, simply moving the mouse pointer or selecting an item in a ComboBox (or any other control) should not cause lag.

A minimal example can be found at https://github.com/DmitryEvstakhov/MapsuiPerformanceTest
In the example, a specified number of lines with varying numbers of random points are rendered on the map. It looks messy, but provides a good performance load. When the number of lines exceeds 1000, the difference in tooltip display speed between Panel 1 and Panel 2 becomes clearly noticeable. A significant delay is also clearly visible when opening the ComboBox.

[pauldendulk]

Thanks for the minimal example! That helps a lot. I cloned it and played around with it.

Some questions and remarks

• I want to know what exactly you see as the problem. Some of the performance issues a general known issues. Those could be countered with the suggestions below. But perhaps there are also other things here, which?
• "When moving the mouse over" is this just moving or also dragging?
• Did you have the same problem in WPF? (perhaps it is not easy to compare it, I don't expect you to rebuild this thing WPF).
• I check if the PointerMoved event is called when there is control on top of the map and it is not, so this can not explain the fact that things are slower when you move over control on the map.
• I see a quick rise of memory use to 4 GB by just resizing the app. Not sure where that comes from. I tried resizing the Mapsui samples but see nothing similar so far. Do you know what could explain this?
• The slowness while opening the dropdown could be caused by the extreme memory usage.
• You inherit SyncLayer from Layer, while it seems to do mostly the same as in Layer, perhaps it is better to inherit from BaseLayer, or just use Layer (not sure what SyncLayer is introduced for).

General Performance Improvements

If you have a fixed number of features it is better to read all the features first and assign them to the Features field of the MemoryLayer, there will be no repeated fetches.

When dragging the map we draw all the feature individually on every iteration. For some scenarios this is what you want, for instance when you are zooming in on point symbols or labels (you don't want them to expand). For lines and polygon it is often good enough to draw a rasterized version of the features. This can be done with the RasterizingLayer.

[DmitryEvstakhov]

Thank you for helping to solve the problems!

The main issue is that the application experiences significant slowdown without direct interaction with the map itself or the objects on the map, after the initial data loading and rendering.

The following points can be identified:

1. VisibleFeatureIterator.IterateLayers() is called when moving the cursor over the map. At this moment, the map itself does not move, no objects are moved, and their geometries do not change.

2. VisibleFeatureIterator.IterateLayers() is called when interacting with controls
   2.1. If the control is positioned over the map, IterateLayers() is called once when hovering the cursor over it. If the element is located near to the map, IterateLayers() is not called.
   2.2. If you try to expand a ComboBox, IterateLayers() is called once, regardless of where the element is located.
   2.3. If you press on the TextBox located near to the map, IterateLayers() is called once.
   2.4. If you press on the TextBox positioned over the map, IterateLayers() is continuously and iteratively called while the cursor remains in the text box.

In our WPF project, we do not observe this behavior. I have also created a similar example in WPF where these issues do not occur, even though the projects are essentially identical. Additionally, I have simplified SyncLayer to use the logic of Layer itself. Currently, it contains nothing except the ability to write messages to the Debug console.
The example is located in the same place.

We use Layer to load objects from the database via IProvider. Objects must be able to change their position and geometry. MemoryLayer and RasterizingLayer aren't suitable for us, in my opinion.

The observation about memory usage is very interesting. Moreover, the difference between WPF and Avalonia is more than 10x. However, I cannot explain this yet.

[pauldendulk]

VisibleFeatureIterator.IterateLayers() is called when moving the cursor over the map.

ah yes! this is easily noticeable in the FPS widget updates. And this is not the case in WPF, and not in Blazor, but it is in MAUI (did not look into anything else). I see we do an explicit RefreshGraphics in the mouse move in Avalonia and MAUI. If I remove it superficial testing indicates that everything just works. There might be some edge case for which this was added, but I think we just have to remove it and then deal with this edge case later. It is also entirely possible that this is a relic of an earlier phase of the event refactoring, it went through quite a few changes. So, my plan is to make a PR to remove this.

You also mention some other events where a refresh happens. Some of those can be caused by this same problem, others are likely related to how Avalonia refresh works. We could investigate that later.

We use Layer to load objects from the database via IProvider. Objects must be able to change their position and geometry. MemoryLayer and RasterizingLayer aren't suitable for us, in my opinion.

If the data changes you could still call refresh on a rasterizer, or update the feature of a MemoryLayer. Here is an example of RasterizingTileLayer with dynamic points:
https://mapsui.com/v5/samples/#/Performance/RasterizingTileLayerWithDynamicPoints

The observation about memory usage is very interesting. Moreover, the difference between WPF and Avalonia is more than 10x. However, I cannot explain this yet.

I added your provider as a sample to Mapsui (have to improve and then I will make a PR) and I see a difference of 240 MB versus 900 MB. Not 10x but way too much! This might be a harder problem to fix because it might not be fully in our own hands. Perhaps you can investigate what impact memory the most (tile layer or vector? styles?).

[pauldendulk]

I created this PR #3293

[pauldendulk]

Regarding the memory consumption you could play with the rendering settings in your Program.cs.

using System;
using Avalonia;
using Avalonia.ReactiveUI;

namespace AvaloniaMapsUiTest
{
    internal sealed class Program
    {
        // Initialization code. Don't use any Avalonia, third-party APIs or any
        // SynchronizationContext-reliant code before AppMain is called: things aren't initialized
        // yet and stuff might break.
        [STAThread]
        public static void Main(string[] args) => BuildAvaloniaApp()
            .StartWithClassicDesktopLifetime(args);

        // Avalonia configuration, don't remove; also used by visual designer.
        public static AppBuilder BuildAvaloniaApp()
            => AppBuilder.Configure<App>()
                .UsePlatformDetect()
                .With(new X11PlatformOptions
                {
                    RenderingMode = new[] { X11RenderingMode.Egl }
                }) 

                .With(new Win32PlatformOptions
                {
                    RenderingMode = new[] { Win32RenderingMode.AngleEgl },
                    CompositionMode = new[]
                    {
                        Win32CompositionMode.WinUIComposition,
                        Win32CompositionMode.DirectComposition,
                        Win32CompositionMode.LowLatencyDxgiSwapChain
                    }
                    ,
                }) 

                .With(new SkiaOptions
                {
                    MaxGpuResourceSizeBytes = 1024 * 1024 * 1024
                })
                .WithInterFont()
                .LogToTrace()
                .UseReactiveUI();
    }
}

[DmitryEvstakhov]

I have tried various rendering settings. In Avalonia, regardless of the rendering parameter combinations, a considerable amount of memory is allocated for rendering. If the MaxGpuResourceSizeBytes parameter is not specified, the memory is released quickly. However, if this parameter is set as before, the memory remains allocated for quite a long time.

Ultimately, if you keep the default rendering settings and do not override MaxGpuResourceSizeBytes, approximately 1.5 GB is allocated for the initial rendering of 1 000 lines. Afterwards, the memory is released quickly. However, each time you interact with any control, all objects on the map are re‑rendered, with memory being re‑allocated.

In the case of moving the mouse pointer, the issue is clear: RefreshGraphics was being called repeatedly, which caused the slowdown.

But, for example, when expanding a ComboBox or changing the value of a Slider, redrawing also occurs, and the reason for this is unclear.

I have noticed another peculiarity. Suppose there is an element (e.g., a Label) positioned over the map. When you change its content (via binding), re‑rendering occurs and VisibleFeatureIterator.IterateLayers is called. However, if this Label is located next to the map, no re‑rendering occurs when its value is changed. I have added this to the example. The console shows that GetFeatures is called when the value of Label1 is changed, but it is not called when the value of Label2 is changed.

[pauldendulk]

Did you also try the various rendering modes? In the builder a couple are mentioned, you could enable them one by one to compare. Especially Win32RenderingMode.Software might behave completely different.

    public static AppBuilder BuildAvaloniaApp()
        => AppBuilder.Configure<App>()
            .UsePlatformDetect()
            .With(new Win32PlatformOptions
            {
                // Not in v11. Is there an alternative?: EnableMultitouch = true,
                // Egl does not work on all platforms for example not on Windows on Arm so only use software rendering for now.
                // This was in earlier versions AllowEglInitialization = false
                RenderingMode = new ReadOnlyCollection<Win32RenderingMode>(new[] {
                    Win32RenderingMode.Vulkan,    // Try Vulkan first (fastest if supported)
                    Win32RenderingMode.AngleEgl,  // Try ANGLE first (uses DirectX)
                    Win32RenderingMode.Wgl,       // Then try native OpenGL
                    Win32RenderingMode.Software   // Fall back to software if needed    
                }),
            })
            .LogToTrace()
            .WithInterFont()
            .UseReactiveUI();

But, for example, when expanding a ComboBox or changing the value of a Slider, redrawing also occurs, and the reason for this is unclear.

I have noticed another peculiarity. Suppose there is an element (e.g., a Label) positioned over the map. When you change its content (via binding), re‑rendering occurs and VisibleFeatureIterator.IterateLayers is called. However, if this Label is located next to the map, no re‑rendering occurs when its value is changed. I have added this to the example. The console shows that GetFeatures is called when the value of Label1 is changed, but it is not called when the value of Label2 is changed.

My guess is that this is how Avalonia events work, and not Mapsui related. You could investigate this by creating your own UserControl (Mapsui's Avalonia MapControl is inherited from UserControl).

If you want to dive deeper you could also play around with the SkiaSharp rendering, independent from Mapsui. Mapsui uses a ICustomDrawOperation for this. See the code here: https://github.com/Mapsui/Mapsui/blob/main/Mapsui.UI.Avalonia/MapControl.cs. There may be alternatives for this way of rendering.

[DmitryEvstakhov]

Did you also try the various rendering modes? In the builder a couple are mentioned, you could enable them one by one to compare. Especially Win32RenderingMode.Software might behave completely different.

Yes, I have tried various options. The Win32RenderingMode.Software mode indeed behaves differently from the others. It consumes significantly less memory, and there are no such large memory usage spikes during rendering.

My guess is that this is how Avalonia events work, and not Mapsui related. You could investigate this by creating your own UserControl

I agree that Avalonia renders the window differently than WPF. Avalonia often sends redraw events to the entire visual tree, including the MapControl. Because of this, the MapControl redraws all objects on the map. This is not noticeable when there are few objects on the map. However, it becomes quite noticeable when there are many objects. And probably the only solution as you suggested is to revise the rendering of the MapControl.

[pauldendulk]

Yes, I have tried various options. The Win32RenderingMode.Software mode indeed behaves differently from the others. It consumes significantly less memory, and there are no such large memory usage spikes during rendering.

Ah, that is good to know.

And probably the only solution as you suggested is to revise the rendering of the MapControl.

I working on this PR #3295. I see a performance improvement in your sample.