Enable downloading tiles for High DPI displays

[mfbernardes]

Signed-off-by: Murillo Bernardes mfbernardes@gmail.com

Add support to maps api scale parameter, as documented in https://developers.google.com/maps/documentation/maps-static/intro#scale_values.

Example of new vs current.

Current	High DPI

@dirkhh

[dirkhh]

I certainly appreciate the idea of having hidpi tiles - but of course that comes at a price, especially (again, talking about our specific use case) when you are at a dive site with low quality internet (a stunningly frequent thing, really). Which makes me wonder how we'd decide which ones to use? If the parameter is set and the tiles take too long to load (some timeout?) then fall back to the lower resolution tiles?

I'm trying to look at this bigger picture and not end up with a situation where the user experience ends up being worse on modern devices (which are all high dpi)... Of course, I haven't tried this, I haven't looked at the amount of data that is downloaded. This change will cause us to download tiles that should be about 4x in size, correct?

[neolit123]

I certainly appreciate the idea of having hidpi tiles - but of course that comes at a price, especially (again, talking about our specific use case) when you are at a dive site with low quality internet (a stunningly frequent thing, really). Which makes me wonder how we'd decide which ones to use? If the parameter is set and the tiles take too long to load (some timeout?) then fall back to the lower resolution tiles?

updating the HQ tiles dynamically on runtime based on the internet connection is doable, but there is another problem, which i forgot about and cannot confirm at 100% for the HQ tiles, yet but i'm pretty sure it's the case.

for the language support of tiles we did the following in Subsurface - the user can change the language, but ideally Subsurface has to be restarted and we then clear the cache. because the cache becomes a mixture of old language and new language.

this is due to the cache file names being the same no matter what params are added (language, HQ tiles, etc).

the same mix would happen with the HQ / LQ tiles and therefore we cannot do it dynamically. it has to be done and then Subsurface needs to restart and the cache has to be cleared.

I'm trying to look at this bigger picture and not end up with a situation where the user experience ends up being worse on modern devices (which are all high dpi)... Of course, I haven't tried this, I haven't looked at the amount of data that is downloaded. This change will cause us to download tiles that should be about 4x in size, correct?

4x is a good estimate. from what i've tested on the mobile app with the LQ tiles, i think if we enable HQ tiles by default it would not perform well.

i think we should do HQ tiles only on the desktop if hardcoded. ...or make it optional on mobile / desktop, but on both versions the switch would need a restart and clearing the cache.

[mfbernardes]

I’m aware of HQ/LQ tiles already cached. I just chose not to handle it here, but in the application.

This doesn’t break anything, just continue showing already cached tiles, unless something like you described is done.

I’ll update this patch as proposed and propose code to enable it on subsurface desktop. No change for moble for now.

Answering from the phone, not great for typing long answers, more should come later.

[mfbernardes]

Code updated to use a parameter.

[mfbernardes]

Updated.

On desktop I can't notice any performance difference and at least using map (instead of satellite) I find it looks noticeably better.

[mfbernardes]

Updated. I missed that too and just copied and pasted around.

[vladest]

shouldn't tile size also be changed?

[mfbernardes]

@vladest No, size represents the map coverage area, that stays the same. Scale will ask to get a tile with twice as much pixels (for that same coverage area).