-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Reload maps" takes a long time #647
Comments
@kiozen: Does this operation imply cleaning of the map cache? In the given situation online maps are involved and reloading a lot of tiles may take quite some time. I observe a similar problem when starting QMS. With a big cache the start is rather slow. |
No, the map cache is not cleared. I've just checked it. The problem must be something else. I think the delay in starting is related to the size of the workplace. In my case the startup time in 1.17 is a little longer than in 1.16.1 |
Maybe related to the new rendering of DEM-Data? If DEM data with hillshading is used, see if deactivating hillshading decreases the time to reload maps. Just a guess though. |
The delay occurs when QMS looks for a new maps.... I do not see the relationship with DEMs |
I can't really reproduce the problem. Can you move one map after the other to single down if it is dependent on a single map. |
I send two videos. Although the cursor is not seen, what I do is the same. I reload maps and then try to scroll in the map window. In version 1.16.1 it is seen that immediately after reloading maps you can scroll. In version 1.17 after reloading maps, you cannot scroll for about seven seconds. This is because the map reloading process takes that long when in 1.16.1 it was immediate. 1.mp42.mp4 |
@Phobooky , You have a 2x2m DEM with hillshade active ( IGN MDT02), in my opinion this is what slows you down. And now you will say that in version 1.16.1 you also have the same DEM with hillshading active. OK, but in 1.17.0 the shading is calculated with more detail and smoother, so it can take a bit longer. To avoid this slowing down the redrawing of the map QMS allows you to limit the zoom range at which the DEM is displayed, and the shading is calculated. Let's call it ' smart use of DEMs'. Think that in smaller scales (zoomed out) it makes no sense to calculate a shading with a 2x2m DEM because one pixel on screen occupies more surface than those 2x2m, therefore you will not be able to see all its details and you are slowing down unnecessarily. The logical thing to do is to limit the range of the 2x2 DEM to a very close zoom, and use a 25x25 DEM that starts displaying the hillshading at the zoom level where the 2x2 DEM ends. Basically, you limit the zoom ranges at which QMS will read DEM data for the whole screen area (and will display it) to avoid slowing down, and the magic is that although the DEM is not displayed, it does apply to the tracks you draw or edit. Here is a tutorial on this topic in Spanish: and also in the help and wiki in English: Please try it and let us know if it is working for you. |
I can confirm there was a change in how raster maps (DEM as well as map) are rendered. Now the render process makes use of as many CPU cores as are available. Previously it was just a single core. On a modern CPU with 16 plus cores this is quite an increase in performance. Therefore more calculation power can be spent on rendering hill shading. On older CPUs this can backfire. Also note there are two different shading modes. If you activate both it takes more time. |
First of all, I think I have to apologize because maybe I didn't express myself well. I don't have any problems with DEMs or rendering maps with the DEM. Maybe there are also changes or problems with the DEMs, but that is not the case for me. I opened this bug for another problem. I try to explain it again. In the Maps window, if I want QMS to check it again for new maps, I use the right-click function, pop-up menu and press "Reload Maps". This action takes about 6 or 7 seconds in 1.17 and nothing in 1.16.1. That is my only problem detected. I don't know if I have explained myself correctly. |
Reloading the maps causes a new rendering of the maps. And rendering of maps causes also new rendering of DEM hillshading, imho. Why don't you just try it out by deactivating hillshading, or DEM at all? It would help to find the cause of your described problem. If the issue persists after deactivating DEM, then the cause is not hillshading, if it solves it then DEM hillshading is the cause. |
Deactivate all maps and DEM. And then activate one after another. After each activation try to reload. This is the only way to circle down what's causing the problem. None of us can reproduce it. Therefore it must be something special with your setup. The only way to find out is to circle down what's causing it. |
@frankystone @kiozen I have followed all the steps you have advised me to do. I have been removing DEMs until I have left none. The behavior was the same. I have removed the paths from the DEMs. The behavior was the same. As it was a good clue to deactivate, I continued with the maps. The behavior was the same until I removed all the maps folders. I no longer have any maps or DEM folders set up. Now I put them back in little by little and apparently the performance is better. But it is a false appearance. The issue is that I have 9 views and each online map takes about half a second, which multiplied by the views makes reloading the maps take about 5 or 6 seconds. Since 1.16.1 did not do that, I think it seems that something new does the reloading of maps that causes that if there are many maps online, the process slows down. I think there may be a new cache check for expired tiles or something similar. Thank you very much for the help. |
@Phobooky Thanks for trying it out and your report. Following your last indications I can reproduce it if I open 9 map views. Even if there is no map or DEM active in any of the views. It is also evident how much slower QMS starts up when it have 9 views. (as pointed by @wthaem ) To reproduce:
Considering that that there are no active maps in any of the views: rather than the cache, Could it be related to the read/write of how each view is configured ? Remark:
@Phobooky , apart from that: keep in mind what we said about DEMS, since having them active at all zoom levels increases a lot the time needed to redraw each view in outer zooms . as pointed by @frankystone reloading the maps causes a redraw of the active view |
Just tested on Linux. No delay. I wonder what might be the difference in Windows.... |
My test with windows has been on a VM, so resources are limited. This afternoon I will be able to do a new test on a laptop with windows10 and I will post here the result. |
My tests are with Windows 11 Pro 21H2, i7, 32.0 GB and obviously SSD. |
This is the result of the last tests I have done: Tests conditions:
Results:
Also:
Summary The only way I can reproduce the problem is if all these circumstances are present: Lots of views x Lots of maps x Maps path pointing to a shared folder in a VM In my case it is the same result for both versions 1.16.1 and 1.17.0. With this result, and unless someone gives more concrete hints, it seems to me that this issue is more dependent on the circumstances in which I play than on the QMS code. @Phobooky , maybe you can try path by path to see if you can better circle down what is causing the delay for you. |
@mitxel-m Thanks for the analysis. But I was a little surprised. My problems do not occur with a VM, so it is clear that I have to investigate more to try to focus the problem. I will keep you posted on my tests. |
I've been doing a lot of testing, and I can't figure out the problem with the map loading delay. The most notable and amazing thing is what I tell you here. Tests conditions: Steps: Summary |
Since I was not satisfied with the little help I am giving you to locate the problem, I did another test. Tests conditions: Steps: Summary
|
Sorry, some of my logfile test output made it into the installer! Examples:
I'll remove this additional output from the logfile and build a new installer! Sorry again for this. |
@wthaem No problem. We are here to help. |
In the logs there is one line that startles me: " Failed to create projection: " +type=crs"". " +type=crs" is no valid projection string. It's probably just a part of one. I can't tell if that is the reason. At least i can not imagine how that should delay something. But you should get rid of that. Might be a bit of a search. Updating the map list simply parses the given paths for known map file extensions and adds a list item. By that the file is opened, read and a MD5 hash is created from the content to identify the map. This is all secured by a mutex, therefore only one view at a time can do that. Usually this operation should be fast. If something delays the file I/O serializing the access for all views will add up to a delay that can be seen by the user. But as said reading up to 16k form a file shouldn't be a problem on a modern OS. |
Thanks. I'll try to investigate a little more to see if we can locate the problem. |
The first test I have done is to use exactly the same configuration, but with 1.16.1 and the surprise is that with that version it works correctly. That's why I think it's a problem with 1.17. What do you think?
|
@kiozen: Can the failing projection be caused by some missing or wrong proj files and therefore be caused by my Windows installer? If so, where to look for the missing files? On my machine, the 1.16 and the 1.17 file sets are equal with the exception of libz/zlib DLLs (MSYS==>MSYS2 change) and of course with the exception of the timestamps). I tested the 1.17 version with a few TMS based OSM and other maps and didn't see any projection issues in the logfile. Loading of the tiles was from time to time rather slow, but this was certainly caused by a slow map server. Remark: I didn't change the projection used in the map window. |
Hi @Phobooky It seems to me that the delay occurs in that line that surprises kiozen and that we don't know where it comes from. @Phobooky Also, to limit where to look, can you do these tests please?
Test 1
Test 2
This will help us to know if we limit the problem to TMS maps. |
I agree with you on diagnosing the problem and when it occurs. Regarding the tests, I have installed the zip that you provided me as you said and these are the results: Summary: with your files it works correctly. Test 1
Test 2
As an example, I attach one of the files with which I have problems.
|
@Phobooky :Thank you. This confirms the same result I got in my VM. @wthaem I think there is not a problem with missing proj files, because these last two tests use the same CRS than a TMS and don't give any errors. That was the purpose of the test. The only difference with QMS 1.16.1 for windows, or even with QMS 1.17.0 compiled for linux, may be that your latest build uses a newer version of GDAL(3.7.2) / Proj (9.3.0), and that may create some difference in how it processes a CRS. Maybe that's why this problem hasn't been triggered until using this latest version of GDAL/Proj. I'm not sure, this is a guess because gdal warns that using proj strings to encode a CRS is no longer recommended.
I checked the code and CMapTMS.cpp uses a proj string. As a first step we can try to replace it with EPSG code. I'm not sure if this will solve the problem because CMapGEMF.cpp for GEMF also contains the same string and doesn't fail, but since proj recommends to replace them it's a starting point that wouldn't hurt. I can search if there are more such strings and replace them with EPSG code, and do a PR. |
I still do not see why this adds delays, but we should give it a try. I would expect PROJ to fail or work. Parsing these strings is no witch craft. But EPSG code are a much more sane way to handle projections. Btw the warning is from the QMS code:
Therefore _strProjSrc is " +type=crs" and that is obviously no correct projection. This happens when a source projection is an empty string. The " +type=crs" is appended if it is missing. As there is nothing else the projection string must be empty aka no projection has been found. |
That makes me feel better.
Can do it, if necessary. |
As I wrote in (#649) the problem has been solved. |
Nice. Thanks everyone for the patience and all the brilliant work! I will close this ticket and we proceed with #649. |
Describe the bug
"Reload maps" takes a long time
What have you done to circle down the problem?
The "Reload Maps" option is very slow compared to 1.16.1
In 1.16.1 it is practically instantaneous and in 1.17 it takes quite a few seconds depending on the number of maps. About 7 or 8 seconds
for six map paths.
To Reproduce
Expected behavior
comment: # Instant response as 1.16.1
Screenshots
Attachments
N/A
Tracebacks
Desktop
Additional context
The text was updated successfully, but these errors were encountered: