Help with Qt6/QtLocation
-
I am having a serious problem right now with Qt 6.10.2 using QtLocation related to memory usage.
I am using the native Maplibre plugin but I also validated this issue happens with the stock osm (Open Street Maps) plugin so I don't think Maplibre is at fault.
I ran an overnight test:
- On Windows 11 the Qt UI application grew from 350MB of RAM to 28GB in 18hours.
- On an embedded Yocto Linux platform the same application grew from 350MB to 2150MB in 18 hours.
- The growth is slow and steady I plotted the increase its linear.
During this test I ran a looping "route" where the map would continually recenter/rotate the map/rotate/move the icon for the current location at 5hz (I know this is frequent but it yields a smooth movement on the map).
currentLocation is a MapQuickElement that as an Image/MultiEffect(for tinting/color) and a MouseArea in it. I wonder if the MultiEffect on top of the map might be a problem?
In the most basic terms this is how I interact with the map. I interact with the map like this at 5hz. It seems doing this leads to linear memory growth that has no maximum.
map.center = QtPositioning.coordinate(nextLat, nextLon) // recenter mapView.map.bearing = targetBearing360 // heading currentLocation.coordinate = QtPositioning.coordinate(lat, lon) // icon position currentLocation.rotationValue = rotation // icon rotationAny ideas? I am going to try reverting to Qt 6.9.1 in the meantime which I used the initial version of my project. I'll update with the results.
Thanks!
-
Ok I reverted to 6.9.1 and the same issue is present.
I noticed something interesting though if I minimize the Qt application window (while my test is running) then the RAM levels off instantly. As soon as the UI is visible again the RAM begins to climb at the same rate as before.
That is a big clue but I am not sure what to make of it.
Ideas?
-
I did not work with Quick but I used webengine view + qwebsocketserver + leaflet.js
//My Obj struct Device{ QGeoCoordinate coordinate; double bearing; }; // Websocket server void sendToClient(){ QJsonObj obj obj["lat"] = dev.coordinate.latitude(); ... } // js client socket.onmessage = event => { const message = JSON.parse(event.data); parseData(message) }After you can use leaflet functions for center view and rotate icon.
2 option have for rotate icon :
-
rotate img tag with css style
-
use leaflet.rotatedMarker.min.js
-
-
One way you could help diagnose and fast track this issue is by running your app through Heaptrack to find out what leaks (with debug informations and optimizations)
-
Thanks for the replies.
I originally tried running Maplibre JS via Webengine and that worked but the performance was terrible on an embedded system (based on Raspberry Pi CM4). The native mapping is far superior in pretty much every way.
Good call on Heaptrack I actually did that last week but I only had a basic report so maybe I need to look at debug optimizations if I understand what you said correctly.
Here is a graph from heaptrack that confirms there is absolutely an issue. It is allocating memory linearly and from what Heaptrack said the allocations are mostly 32-64 bytes in size.
I have isolated the issue to anything that recenters/rotates/tilts the map view. If disable all this the memory growth stops. If I adjust the frequency of recentering/rotation the map I can adjust how fast the memory grows. The problem is that to make the map a smooth experience akin to say Google maps these parameters need to be animated at like 30fps at least to achieve really smooth navigation.
Also since I ruled out the Maplibre plugin (because it happens with the osm plugin too) I am leaning more toward there being a bug in QtLocation/QtPositioning that allows unbounded memory growth. I haven't been able to find a bug yet though still looking.
-
Any possible culprits in the called functions list of Heaptrack?
-
No the caller list just lists one unresolved function. I tried cross compiling the UI with debug symbols to run on my embedded system with heaptrack but I got the same result.
I tried running Valgrind on it too but I think to make that really work I need to setup a native Linux Qt development environment.
I already tried that but I did it in a VM and it was weird. Open street maps had no issue with ram it was steady on the Linux VM. But Maplibre wouldn't run and I suspect its the VMware graphics drivers causing it to fail to start.
I did change something that I believe had a huge impact. My map was a singleton and I tried just putting the map straight into the qml and it seemed to really reduce the memory growth. I'm not sure what to make of it.
On Windows this is what I'm seeing now with the Private Bytes. Though from what I've read this isn't really a good indication of a memory problem but it does look kind of linear.
-
Partially Solved!
Ok I have good and bad news related to this issue.
The good news is that for my Linux x64 Ubuntu VM and for my Yocto embedded aarch64 Linux system I was able to solve the issue.
The problem was that the qt maplibre native github repo was v3.0.0 when I started off this whole mapping project. However when I updated to Qt 6.10.2 I pulled the github repo and it had been incremented to v4.0.0.
Maplibre Native Qt v4.0.0 is still in active development and is not an official release.
Simply reverting to Maplibre Native Qt v3.0.0 fixed the issue on my Linux VM and embedded Linux system. All while using the latest Qt 6.10.2.
Bad News
On Windows there is still a huge memory growth issue. It starts off around like 400MB and rises like 1MB every couple seconds. This happens with using the Maplibre v3.0.0 plugin as well as the OSM plugin.
I discovered something interesting though with a single line of code:
//in main.cpp if I set this which is required for the maplibre plugin to work the memory growth // issue occurs with Maplibre and OSM mapping //with the OSM ram starts at 450MB, grows 1MB every couple seconds QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL); //if I switch over to using this instead, Maplibre stops working but the OSM plugin still works and the memory is stable //with the OSM plugin in use I observed the ram use starting at 280MB which grew to about 290MB and leveled off //if there was any growth it was small, it was stable not out of control growth like with OpenGL QQuickWindow::setGraphicsApi(QSGRendererInterface::Direct3D11); //I didn't test this but I assume this would also not have a problem too I will try it later QQuickWindow::setGraphicsApi(QSGRendererInterface::Direct3D12);So at this point I believe there is a bug in the Qt 6.10.2 framework related to utilizing QSGRendererInterface::OpenGL specifically on Windows.
I am thinking about making a Qt bug report for it. I have a test application mocked up that replicates the issue. It is either an issue with QtLocation/Positioning specifically or it might be a more widespread issue that is exacerbated by constant map updates trigger lots of rendering.
If you have any ideas on things I could try on Windows please let me know.
-
Partially Solved!
Ok I have good and bad news related to this issue.
The good news is that for my Linux x64 Ubuntu VM and for my Yocto embedded aarch64 Linux system I was able to solve the issue.
The problem was that the qt maplibre native github repo was v3.0.0 when I started off this whole mapping project. However when I updated to Qt 6.10.2 I pulled the github repo and it had been incremented to v4.0.0.
Maplibre Native Qt v4.0.0 is still in active development and is not an official release.
Simply reverting to Maplibre Native Qt v3.0.0 fixed the issue on my Linux VM and embedded Linux system. All while using the latest Qt 6.10.2.
Bad News
On Windows there is still a huge memory growth issue. It starts off around like 400MB and rises like 1MB every couple seconds. This happens with using the Maplibre v3.0.0 plugin as well as the OSM plugin.
I discovered something interesting though with a single line of code:
//in main.cpp if I set this which is required for the maplibre plugin to work the memory growth // issue occurs with Maplibre and OSM mapping //with the OSM ram starts at 450MB, grows 1MB every couple seconds QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL); //if I switch over to using this instead, Maplibre stops working but the OSM plugin still works and the memory is stable //with the OSM plugin in use I observed the ram use starting at 280MB which grew to about 290MB and leveled off //if there was any growth it was small, it was stable not out of control growth like with OpenGL QQuickWindow::setGraphicsApi(QSGRendererInterface::Direct3D11); //I didn't test this but I assume this would also not have a problem too I will try it later QQuickWindow::setGraphicsApi(QSGRendererInterface::Direct3D12);So at this point I believe there is a bug in the Qt 6.10.2 framework related to utilizing QSGRendererInterface::OpenGL specifically on Windows.
I am thinking about making a Qt bug report for it. I have a test application mocked up that replicates the issue. It is either an issue with QtLocation/Positioning specifically or it might be a more widespread issue that is exacerbated by constant map updates trigger lots of rendering.
If you have any ideas on things I could try on Windows please let me know.
@MyUsernameIsUsername said in Help with Qt6/QtLocation:
QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL);
I use it for Windows, but I've never needed it for Linux(Ubuntu). I'm glad you solved the problem. I hadn't thought of this issue because I assumed you were using QML.
