[BUG] TileLayer `updateInterval` is not working

[rorystephenson]

What is the bug?

TileLayer's updateInterval option has on affect. This causes fetching and loading a lot of tiles when flinging or animating the map a long way.

What is the expected behaviour?

Presumably the documented behavior of updateInterval:

/// Tiles will not update more than once every `updateInterval` (default 200
/// milliseconds) when panning. It can be null (but it will calculating for
/// loading tiles every frame when panning / zooming, flutter is fast) This
/// can save some fps and even bandwidth (ie. when fast panning / animating
/// between long distances in short time)

How can we reproduce this issue?

This is easiest to notice when animating the map a long way and watching network requests for tiles. I will probably add a recording to demonstrate this at some point.

Do you have a potential solution?

Re-instate the throttling logic so that updateInterval works again.

Can you provide any other information?

I wanted to determine why so many tiles were being loaded when I animated the map position across a large distance and after a quick look at the TileLayer code it is apparent that updateInterval has no affect. Similarly the throttleUpdate StreamController is being initialized and disposed but it is not hooked up to anything.

It seems that as part of #1333 this commit commented out throttling code with a // TODO fix note but it's not clear whether the throttling code was broken already or if it was broken during that PR and the author forgot to fix it before the PR was merged. I intend to re-instate the throttling logic and if it was already broken that would be helpful to know in order to avoid recreating any bugs.

Platforms Affected

Android, iOS, Web, Windows, MacOS, Linux

Severity

Obtrusive: Prevents normal functioning but causes no errors in the console

Frequency

Consistently: Always occurs at the same time and location

Requirements

• I agree to follow this project's Code of Conduct
• My Flutter/Dart installation is unaltered, and flutter doctor finds no relevant issues
• I am using the latest stable version of this package
• I have checked the FAQs section on the documentation website
• I have checked for similar issues which may be duplicates

[ibrierley]

Good spot!

[rorystephenson]

Measuring

OK I've just running some logging code on the AnimatedMapController example using the current master (3e8368d) and against the last commit which contains the unbroken updateInterval code.

In both versions I modified the target Paris zoom to 10 and added a custom TileProvider which recorded and printed the tile fetches since the last tap. Then I tapped, in order: "London", "Paris", "Dublin.

Here are the number of tiles loaded each time for both versions:

	1.initial load	2.tap london	3.tap paris	4.tap dublin
master	6 tiles	53 tiles	49	77
last working version	6 tiles	53 tiles	19	36

Tapping to zoom to London caused the same number of tile fetches in both versions whilst the subsequent taps of paris and dublin saw significantly less (but still a lot) of loads with the old working code. The fetches could be further reduced by increasing the updateInterval at the cost of slower tile loads.

Towards a fix

Given that updateInterval is not working right now I think it's worth considering alternative fixes before reinstating the old behaviour. The updateInterval flag reduces the number of tiles fetched but also introduces a delay in loading. Ideally the choice to delay/avoid loading a tile could take in to account what caused the tile load in the first place. Some examples of how we might want the loading behaviour to vary:

• Panning: Load immediately since panning tends to involve moving across small distances
• Zooming: It would be nice to optionally be able to wait until the zoom is released (not always possible, e.g. scrollwheel zoom) before loading new tiles.
• Animated movement: This would depend on the distance and style of movement (e.g. just panning vs zoom out then pan then zoom in). When panning across a long distance fast the current implementation loads a LOT of tiles. It would be better to be able to start loading the destination tiles as soon as the movement begins and worry less about the intermediate tiles.

These are just some examples off the top of my head and such specific behaviours would need to be configurable. I think it would be worth considering other use cases and then see if we can come up with a clean way to implement them.

---

Aside from that it looks to me like like the tile layer code could use some love and some tests to avoid regressions.

[ibrierley]

So out of interest, what happens on a large zoom/pan...do you get grey missing tiles in the middle of a pan, when panzooming to a new distant location (apologies, not able to test for a while)?

[rorystephenson]

During the pan they are grey and missing but only because the panning is so fast that there isn't time to download the tiles in time to show them before they are out of view. They are eventually all loaded which means a bunch of unnecessary requests for tiles. It also means that the tiles at the destination take a while to show up since so many requests are fired off.

[ibrierley]

I wonder if there's some inbetween solution where during a fast pan a few tiles at a lower zoom level (so not many tiles needed) are loaded, so they would be a bit blurred but typically doesn't matter during movement. I guess question maybe whether they'd be loaded in time to be worth it. Also I don't think the tile layer typically knows much about the state, destinations etc etc, but something could possibly be thought out there.

[rorystephenson]

EDIT:

Looks like tile coordinates are always rounded 🎉 :

flutter_map/lib/src/layer/tile_layer/tile_provider/base_tile_provider.dart

Lines 29 to 31 in 3e8368d

	'x': coords.x.round().toString(),
	'y': coords.y.round().toString(),
	'z': z.round().toString(),

---

I'm digging in for a big refactor again as I'm unable to make sense of the code as is. There are expensive calls in the build method, including calling setView twice in a row during build.

As part of this refactoring there is one thing in particular which has struck me as odd that I've love some clarification on if anyone can help. As far as I can see tile zoom levels are always whole numbers (the map zoom level is not but the tiles are fetched with whole number zooms) yet the minNativeZoom/maxNativeZoom are doubles. This makes some of the tile code messy and prevents caching some calculations per tile zoom level since if the tile zoom levels can be double then there are potentially too many different tile levels to cache. So I'm wondering if minNativeZoom/maxNativeZoom can (should) actually be integers?

TL;DR
Is there any use case for minNativeZoom/maxNativeZoom being doubles or can I change them to ints?

[JaffaKetchup]

Thanks @rorystephenson :)

In my mind, it would be OK for those properties to be ints, as they are more directly related to the tile layer, and don't actually restrict zooming in any way.
For clarification, the normal zoom limits should remain doubles.

[JaffaKetchup]

See #1475.