Replace QPainter with Blend2D in CMapIMG#1131
Conversation
|
First quick impression:
|
|
From a package maintainance perspective those shouldn't be a big thing.
They are pulled in via cmake automatically and we manage their version by setting a git tag. Almost no distro packages these so we don't even have to handle the option to build against system versions.
Strange... For me it's the difference between often >1s per draw to ~300ms which is quite a large difference in usability.
Your GPU should not make a difference. Blend2D is a pure software rasterizer so runs only on CPU. With the profiler you could easily check what impact reading the data has
as the loading step will show up as it's own zone.
|
|
My attempt to build the PR jmlzr:QMS-1130 with my default CMake parameters failed on Windows 11: There are lots of new CMAKE variables. I used their default settings. More info is certainly needed to build successfully on Windows. Must there any additional packages be downloaded before building? Sorry for the message layout - I copied it from the output log. |
|
@wthaem Yes cmake will need to download a few packages via FetchContent. Can you check at the start of cmake output if that failed or something? If you run cmake directly it should normally already fail at that point though... If you had the build directory already before switching to this branch you could maybe try cmake with |
|
same problem on a Linux machine. Even with cmake from scratch. The tracy header path is not set properly for the target. |
|
I'm starting the build always with The file Edit: ChatGPT info: "Does ROCprofiler-SDK exist on Windows? Officially: no, not as a supported Windows package." How to switch off the use of tracy? My settings: |
Add the profiler Tracy to the project and start instrumenting some functions relevant to IMG rendering. With tracy turned off at compile time this won't add any overhead. Having a profiler available is essential to guide performance improvements. To use it turn on tracy with -DTRACY_ENABLE=1 then build the profiler application itself, launch QMS and the profiler and connect it. The tracy project will end in _deps/tracy-src inside the build dir.
Dramatically speed up IMG rendering by replacing the very slow Qt vector engine with the much faster Blend2D for all but text rendering.
|
I'm sorry I should have read your error message more carefully! Turns out I accidentally added an include to a qmaptool file (and qmaptool is not linked with Tracy). Since I always just built the qmapshack target I did not notice. I fixed that by removing the include and confirmed that now all our targets build successfully. You can ignore that missing rocprofiler. That's just an optional dependency of Tracy we don't need. |
|
Now building is ok and nothing special noticed with a quick first test (KMz now again without blurry). |
|
Sure: the KMZ topic belongs to the other PR. But I noticed again the difference in quality with this PR. I tried IMG maps and many types of raster maps. Loading, zooming, panning of IMGs was pretty quick. Image quality on my notebook screen quite good. My notebook has a good CPU! |
|
Currently, I am trying to build on macOS. I get tons of warnings like these: Might it be possible to expand cmake configuration not to throw these warnings? |
|
@JFritzle Pretty sure that's the same issue I already described in the PR description and Apple's clang just uses a different wording for that warning then GCC:
|
|
Did not notice a performance improvement with map Reit_Wanderkarte_Italia_11_25.img on my Windows 11 PC: |
|
Haven't had the guts to deal with Tracy yet. But my hands-on experience is similar. On my high performance work laptop I can notice a small difference in performance. On my old private laptop no noticeable gain. But on both machines I have to increase the details level quite a lot to get a noticeable lag. More than I usually would do. So the benefit is on the lower side I am a bit undecided. Pulling in new dependencies is always a risk and makes me feel uneasy. On the other hand side I highly appreciate and acknowledge every work donated to QMapShack. This places me in between chairs. It's always a hard decision based on the estimated future of the feature. Will it cause more benefit than future trouble? There is already quite some stuff I would like to get rid of (alglib, quazip) either by kicking out the feature or replacing it with native code. Dropping features is always trouble because of this one user popping up actually using it. And replacing code is another problem on it's own. For example what happens if I have to decide that blend2d can't be used anymore for whatever reason. I have to revert to Qt. Users might notice the performance loss and complain. Restoring the former code is possible. But might be more trouble than expected. So there must be a benefit worth it. For example replacing the QMapShack native code with the Garmin SDK was a tough decision, too. Apart from a not 100% clarified license situation, it's now depending on Garmin's lib. On the other hand side, the native code was done ages ago by someone not reachable any more. The newer devices implement new features that require to actually notice the change (reported by users), understanding the rather complex code and fixing the stuff without breaking something. To get rid of this maintenance burden picking the Gamrin Lib was a choice. So long story short: I am still undecided. Even after writing all of this. |
|
That's very strange. I guess you guys must be either using maps only in areas with very little features or have screens with low resolution if you don't have noticeable lag with the previous renderer. @kiozen I don't get your point tbh. If you ever wanna get rid of Blend2D you can just revert. It will only be used in the IMG renderer and that one is unmaintained since a while anyways, so not even like there is much of a chances of there being changes that then might need back porting. Most importantly: Why would a user complaining about performance in the future after a hypothetically possible revert matter more than one complaining now about current performance? |
4 participants
What is the linked issue for this pull request:
QMS-#1130
What you have done:
Added Tracy as a profiler and instrumented the IMG rendering to look for where to focus my performance optimization efforts. That showed that Qt's rasterizer is the bottleneck that will dwarf any gains that could be made in the code. With the biggest bottlenecks being
drawPolylinesby and followed bydrawPolygons.So I decided to let Claude replace Qt's very slow rasterizer with Blend2D which is probably the fastest software rasterizer/vector graphics library in existence.
The new code seems to result in the same output but runs ~3 times faster!
Performance comparison
To make a comparison I recorded traces of me panning and zooming around the same area before and after the commit that switched to Blend2D and then used Tracy's compare feature.
drawPolylinessaw a massive 5x improvement, dropping from 569ms mean to 117ms:drawPolygonssaw a also impressive 2.5x improvement, from 170ms to 67ms:Looking at
drawis deceiving as the results of that are diluted by early exists from redraw requests.Render output
I took comparison screenshots before of the same view before and after, map used is a Freizeitkarte IMG.
Before:
After:
As you can see there is virtually no visible difference! The only thing I can notice on this view is the POIs shifting a little but they seem to shift by a similar amount with the previous renderer as well when panning minimally so I'm not sure if that is even a regression.
Next steps
Since this is a rather large change and I haven't checked if Claude did stupid things I made this just a draft for now. I do encourage people to try it out though!
I think now that the biggest bottleneck is gone I could also squeeze out probably at least another ~20% from optimizing the rest of the code.
Btw the massive amount of
ISO C++ prohibits anonymous structswarnings comes from the fact that our CMakeLists.txt unfortunately sets global compile options withadd_compile_optionsthat then affects subprojects as well. The better thing would be to set them only for our own targets withtarget_compile_options. But we can fix that if we get close to merging this, for now I didn't want to bother with that.Steps to perform a simple smoke test:
Open a IMG.
Tracy
If anyone wants to play with Tracy:
-DTRACY_ENABLE=1 -DTRACY_ON_DEMAND=1./profiler/build/tracy-profilerand connect to the running QMS instance.Does the code comply to the coding rules and naming conventions Coding Guidelines:
Is every user facing string in a tr() macro?
Did you add the ticket number and title into the changelog? Keep the numeric order in each release block.
No as only a draft for now.