Seeking performance feedback: Multi-layer GeoJSON rendering with TMapViewer

[Xenno]

Hi everyone,

I am currently refining the map viewer module for my Windows utility, BS QuickView, which utilizes the TMapViewer component.

As the app continues to grow, I am specifically looking for technical feedback on how the current engine performs when loading multiple GeoJSON files as stacked layers in real-world usage. I am interested in hearing from anyone who has experience with multi-layer rendering in TMapViewer regarding:

• Layer stacking: Performance impacts when rendering more than one overlapping GeoJSON layers (polygons/points) simultaneously.
• Rendering efficiency: Any potential bottlenecks or artifacts observed when scaling to larger datasets (10k+ features).
• Stability: Observations on memory management during high-frequency zoom and pan operations.

BS QuickView is designed for a "concise and seamless" user experience, keeping all operations local, offline (except map data which is from OpenStreetMap), and minimal dependency. The application is currently available on the Microsoft Store, and a free trial version is available for anyone interested in evaluating the rendering performance firsthand.

If you have experience working with TMapViewer or have suggestions for optimizing multi-layer vector handling within this component, I would greatly appreciate your insights.

You can download the trial here: https://apps.microsoft.com/detail/9MZTBRLM7JS7?hl=en-us&gl=ID&ocid=pdpshare

Thank you for your time and expertise.

Best regards,

[Hansvb]

Hi,
I started also with a gisviewer and coincidentally also with geojson as the first format to read in. I also ran / run into speed problems with panning and zooming when there are many objects in the map. What I have been experimenting with is

• Render only the objects that are in view. Ignore everything outside your viewframe.
• Simplify objects when you're zoomed out and therefore need to draw more.
• And I've been experimenting with an index.
• And for the background map use a cache but lazmapviewer already does that itself. You can choose as an option.

I'm going to restart my gisviewer and try to set up the code nicely. When I'm as far as my experimenting project is again, I'll post it on this forum.

[Xenno]

Hi, Hansvb

Thank you for sharing your experience.

[lar]

My use of TMapViewer bypasses its built-in display panel and instead uses a custom TMapServer class to retrieve a bitmap image from TMapViewer's components on demand (see https://forum.lazarus.freepascal.org/index.php/topic,74278.0.html) That bitmap is copied onto a master off-screen bitmap on which additional custom drawing can be made. The master bitmap is then blasted onto a TPaintBox panel for viewing. The attached image shows an OpenStreetMap base map with 150,634 nodes (circular ellipses) and 157,044 links (line segments) drawn in under a second using only LCL graphics.

An extension of this approach to handle multiple map layers stored in files (as in GIS) would be to employ separate BGRA transparent bitmaps for each layer, render the images on each in separate threads, and then copy them onto a master bitmap to display in your viewer.

[Xenno]

Hi, lar

Thank you for sharing your experience.

[marcov]

I myself (unrelated to map) have a small opengl overlay layer for images. hundred thousands of lines and rects are nothing. IIRC mapviewer also has an opengl renderer, maybe test htat ?

[Xenno]

Thank you for sharing your experiences. It is interesting to see that  you are achieving custom results by bypassing the built-in rendering and drawing directly on the canvas.

While I see the value in that granular control, my design philosophy for this app is to prioritize 'out-of-the-box' component performance. I am leveraging the full, native functionality of TMapViewer to keep the codebase lightweight, maintainable, and easy to extend.

I have been enjoying the power of the TMapLayer structure; using TMapArea, TMapTrack, and TMapPointOfInterest has made organizing my layers very straightforward. Sticking with the default drawing engine (TMapViewer can be told to use RGBGraphics and BRGABitmap) meets my current requirements for speed and functionality perfectly. I am confident that this concise approach provides the seamless, reliable experience my users expect. I would love to know how this app performs on real usage.

[Xenno]

Hi, marcov

Thank you for the insight. However, I can't find that TMapViewer supports OpenGL. It has 3 drawing engines to choose: default, RGBGrphics, and BGRABitmap. I will check again about OpenGL in LazMapViewer.

My development device is a low spec computer and I tried to display a map with 5 layers from 5 GeoJSON files and surprisingly it delivers acceptable performance. I had to switch to even weaker puter cause my children needs the one I used before. Now my gear is an HP T630 AMD Embedded GX-420GI 4 GB RAM. This is the computer I use and get the result.

[wp]

However, I can't find that TMapViewer supports OpenGL. It has 3 drawing engines to choose: default, RGBGrphics, and BGRABitmap. I will check again about OpenGL in LazMapViewer.

Correct, there is no drawing engine based on OpenGL, and I must say that I lost interest in OpenGL after their disruptive change from legacy to shader-based rendering.

In https://github.com/PascalCorpsman/Examples/tree/master/OpenGL/Mapviewer, however, you can find an OpenGL-based mapviewer, I guess it is not much compatible with the one found in OPM.

[Xenno]

Hi, wp

Thank you to clarify. I just checked the link. I stick to LazMapViewer.

[marcov]

However, I can't find that TMapViewer supports OpenGL. It has 3 drawing engines to choose: default, RGBGrphics, and BGRABitmap. I will check again about OpenGL in LazMapViewer.

Correct, there is no drawing engine based on OpenGL, and I must say that I lost interest in OpenGL after their disruptive change from legacy to shader-based rendering.

Then, sorry, I was mistaken (confusing with TChart maybe?). 

I was thinking about a situation where you  upload 9 tiles (center + 8 adjacent), and do the rendering (layer selection, zoom/pan and font scaling) with shaders, that would be rather cheap.

There are some problems though, polygons need to be triangulated before upload, which is maybe non trivial for complex polygons.

But afaik many GPS route planners do it this way. I actually looked into one for the signed distance font scaling (to keep (some) text readable at any zoomlevel)

But anyway, then there first needs to be an opengl map drawing proof of concept before tmapview integeration gets relevant.

[Xenno]

Hi, marcov

Thank you for the insight. That's definitely beyond my level as I am more into "Make Use Of" Lazarus user. Nevertheless, I will try to educate myself about it.