mavlink
Very poor performance when moderately large missions are loaded
Current Behavior
When working with moderately large missions (of maybe around 250+ simple waypoints, probably more than the typical use case but still much less than what is currently supported in the main autopilot firmwares), QGroundControl becomes very unresponsive to the point of being unusable, particularly in the Plan View and in low end devices such as Android GCS. In the latter case it can and does crash at any moment, making it unsuitable for operations where the GCS is critical.
Expected Behavior
Adequate performance and stability, at least up to 600 waypoints, which is what ArduPilot supports without an external SD card. Or at the very least the performance of the current QGC stable, where this issue isn't nearly as bad. The model size of even a huge mission is very manageable by any system, so this seems to be due to very innefficient rendering or unnecessary view updates.
Steps to Reproduce:
- Create and load a mission with a large number of simple waypoints
- Pan the view, scroll down the waypoint list, etc.
- The performance will be abysmal at this point. If using an Android GCS, the app will crash within a few minutes.
System Information
- QGC Version: current master
Sample mission
test-250-simple-wp-mission.zip
Are you able to run the QML Profiler? If not I will do so at some point. I'm not really aware of anything that's changed with any of the mission/plan view stuff so I'll have to look into it further
I was going to do it and try and fix the issue but I don't have much time at the moment, so I figured I'd just report the issue. I'll do it later if I can
Haven't tried on Android yet but at least on a high end Linux it works fine. It looks like it is likely MissionItemEditor that is causing the problem though
Maybe is something Windows/Android related, then? I haven't done any profiling but the issue is immediately obvious when compared to the latest stable.
Unless there is some specific control that has gone whacky there isn't much different in the Plan view Stable -> Daily.
Windows is working fine for me as well with the example plan from above
Herelink seems fine as well. Scrolling the waypoint list up/down is a little sluggish but still workable.
Seems like it might be an issue on my end... I'll see if I can find out the reason this week
I'm not able to properly look into it at the moment but here's a video of the issue on a high end Windows: https://github.com/user-attachments/assets/17d23014-ea1d-4526-a5e6-6227bbceb5a0
That's the latest 4.4.3 release vs a Release build of the latest master commit at the time of this comment. Note that on the right (latest master) I'm trying to do exactly what I do on the left, but the view is completely stalled. Then I try the drag gestures which seem ever so slightly more responsive but still what I consider to be completely unusable. I've also done the same test shown in the video while running the QML debugger on a Profile build:
latest-master-250-wp-performance.zip
As you can imagine, on a Skydroid H16 you can't even pan the view at all, let alone edit the mission, and even if you just want to load it and go back to the Fly View the app crashes within minutes. I have also tried the installer artifact from the 9beae12 Windows test workflow and was able to replicate the problem there as well. That being said, if neither of you are seeing the same issue, I guess it must somehow be a problem on my end.
@rubenp02 Can you try setting 'cacheBuffer' to 0 here: https://github.com/mavlink/qgroundcontrol/blob/master/src/PlanView/PlanView.qml#L755
Run it with the profile as well and provide output like you did above.
The performance is a lot better but still pretty bad. Panning the map is now responsive, and the WP list is a lot smoother but still not usable as the attached video shows. You can see I also get a bug where clicking the last waypoint actually opens one of the first elements in the mission, scrolling back the list to almost the beginning.
https://github.com/user-attachments/assets/43a58b7d-7467-4043-a38e-97f8b36b8537
And here's the profiling output:
cacheBuffer-0-latest-master-250-wp-performance.zip
Can you do a profile with a plan which just has say 10 waypoint in it?
My pull will help this a little, but there is still something significantly wrong here.
Here it is with 10 waypoints (.plan file attached):
9beae12-10-wp-performance.zip
test-10-simple-wp-mission.zip
With so few waypoints there's no noticeable difference with the stable. I used 9beae12 for the test and set cacheBuffer to its original value to get a worse case scenario but its completely smooth. Regarding your PR it does improve the performance massively both when panning the map and when scrolling the list or opening mission items, but it's still far from the performance in the stable. I haven't tested if it prevents the Skydroid H16 crashes yet.
It still crashes on the SkyDroid despite the performance improvements and without even entering the Plan View.
Do you know the specs of the SkyDroid? I just tried on a samsung tab active 4 pro and it seemed alright. Also turned on GPUWatch and profiled on the android device itself and stayed 50fps+
It has a 64 bit Pinecone S1 SoC. I don't know much about it, but it seems like its not bottom tier either.
Edit: I see that it's literally the same SoC as in the Herelink. Does GCS latest really not run terribly and crash within minutes when that 250 WP plan is loaded in the Herelink?
I loaded the 250 WP plan on my Herelink and it all worked fine. No perf deg or crashes.
That's very weird... As I mentioned the SkyDroid has exactly the same SoC. I've even tried the Herelink build. I guess I'll just fix it and open a PR.
@rubenp02 I've tried all sorts of ways to reproduce this and can't see any problems. Can you do a run yourself with QML profiling on Windows:
- Build release QGC with qml debugging/profiling on
- Start Qml profiling, turn it of if QGC boots with it on
- Go to Plan, get ready for 250 plan load by going to File/Open and file dialog ready to click Open
- Turn on Qml profiling
- Once plan loads turn off qml profiling
Yeah, seems much, much better. The crashes were also apparently unrelated, I figured out the reason and the fix was recently merged.
This next week I'll rebase our fork on top of everything and test it out for real, to see if it can finally replace stable for us (the only things that were missing were performance and stability). If all goes well I'll close this issue then.
@rubenp02 Have you tried things end to end to see if they've improved?
Ah, sorry, forgot about this.
I had a full week of flights scheduled with a client and wanted to test it there, but it ended up being delayed until the first week of July, so I haven't tested in real world conditions per se yet. In simulated use it all seemed fully on par with stable though, so I'd say this can be closed. But I can hold off until that first week of July if you want a more thorough review.
I'm gonna close and can create new Issue with specific cases if needed. Hoping to mark stable within the next couple days.