-
Notifications
You must be signed in to change notification settings - Fork 22
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
Reduce redundant host loading on map #101
Comments
As an easy thing to implement I would suggest a zoom limit for requests - no request is made until the map shows something like 100x100 miles, instead a message is shown prompting the user to zoom in. This makes sense to do on a mobile device in order to save bandwidth. |
What I was actually talking about is the redundant loading. You're prodding on a different (important) problem, loading too much. But the reality is as I use it casually and move the map, it does a quick load for every move, when often we already have all the info. |
very true - I will open a separate issue. |
Since it starts zoomed in now the problem with being zoomed out too far is less. |
For me that's actually not the case currently, see my comment: #97 |
In order to reduce the number of requests made when panning around on the map, maybe there could be a short 1 or 2 second timeout before the request is made. The timeout would be cancelled every time the map moves so that it fires only when the map has not been moved for 1-2 seconds. |
That's a nice idea @jstaffans, thanks. Might work fine. |
From #10: Currrently the map will always finish loading hosts based on the previous map zoom/scroll before starting to load hosts based on the new one. The old loading should be cancelled as soon as the map zoom/scroll changes. |
Canceling might be possible with AbortableHttpRequest... Doing what I originally suggested, tracking the rects which have already been downloaded, would add a pile of complexity to a situation where the existing functionality is "just fine", IMO. I'm going to remove this from the 1.4.1 milestone and it might even just need to be closed at some point. |
Could be tackled together with #265 |
Users that were loaded from the network are now kept in a cache and only discarded when the app is closed. This means, that if a user navigates away from the map and then comes back to it no more loading needs to be done for the previously loaded areas. Also, the loading is area aware. That means that for overlapping areas requests are now only made for the non-loaded parts. Fixes: #101
Users that were loaded from the network are now kept in a cache and only discarded when the app is closed. This means, that if a user navigates away from the map and then comes back to it no more loading needs to be done for the previously loaded areas. Also, the loading is area aware. That means that for overlapping areas requests are now only made for the non-loaded parts. Fixes: #101
Users that were loaded from the network are now kept in a cache and only discarded when the app is closed. This means, that if a user navigates away from the map and then comes back to it no more loading needs to be done for the previously loaded areas. Also, the loading is area aware. That means that for overlapping areas requests are now only made for the non-loaded parts. Fixes: #101
Every time the map is moved a full request is made to the server for the hosts in that area. It would be nice if we could keep a bounding box or set of bounding boxes of areas already loaded so we could just skip that step if the hosts for the area were already loaded. It would really speed things up.
There might be other ways to limit this redundant loading...
It also might be good to cancel any outstanding host request tasks when the map moves...
The text was updated successfully, but these errors were encountered: