Version: svn (using Devel) Installed from: Compiled sources I think is a bug. The OSM websites is 3-4 times faster than marble...is a bug or only an OSM's API problem?
Hi Fabio, Yes, we have noticed that, too. It's still unclear to us whether the slow download results from: - Marble's HttpDownloadManager and its algorithm or usage of QHttp - Qt's QHttp class - or whether openstreetmap.org treats its webservice in some optimized way. It could be that queries "from the outside" (like those of Marble) could get executed with lower priority. But we don't know whether this is the case. If you'd be able to find out more about the latter we'd appreciate any input from you on this matter.
SVN commit 834839 by jmhoffmann: Fix bug 162681 in trunk (slow tile download). The problem with the download implementation was that there was only one QHttp object in HttpFetchFile, throught which all requests were serialized. Now we have got one QHttp object per active HttpJob, so this bottleneck is gone now. CCBUG: 162681 M +13 -0 ChangeLog M +3 -3 src/lib/HttpDownloadManager.cpp M +65 -37 src/lib/HttpFetchFile.cpp M +13 -2 src/lib/HttpFetchFile.h WebSVN link: http://websvn.kde.org/?view=rev&revision=834839
SVN commit 835029 by jmhoffmann: Fix bug 162681 in trunk (slow tile download). The problem with the download implementation was that there was only one QHttp object in HttpFetchFile, throught which all requests were serialized. Now we have got one QHttp object per active HttpJob, so this bottleneck is gone now. This fix was committed in trunk earlier this day. CCBUG: 162681 BUG: 162681 M +14 -0 ChangeLog M +3 -3 src/lib/HttpDownloadManager.cpp M +54 -35 src/lib/HttpFetchFile.cpp M +13 -2 src/lib/HttpFetchFile.h WebSVN link: http://websvn.kde.org/?view=rev&revision=835029