Occasional slowdowns and Recoloring in Progress pop-up

[falkamelung]

Here is one example where it unnecessarily slows down:

If you keep the original time period it works great (at the beginning of the video). However, if you temporarily change to a different period and go back to the original period (at the end of video), then the slow-down messages show up

https://github.com/user-attachments/assets/4121edcd-08e5-42d8-903f-ef2d9f2a88ef

Actually, would it be possible to give more specific slowdown messages? E.g. to say "Data download in process". when it applies? In the case above it says "Recoloring in progress' although there is no recoloring.

I used this data set: http://149.165.153.50/start/-8.5309/123.5741/15.5355?flyToDatasetCenter=false&startDataset=S1_IW3_090_0622_0624_20170116_20240807_S08552_S08486_E123555_E123591_filtDel4DS&minScale=-0.7&maxScale=0.7

[stackTom]

So basically, the issue is - stop unnecessary recoloring when the dates are back to the full time period?

Note that if a new reference point is selected, we must recolor even if the full time period is selected. The only time we don't have to recolor is when we are showing what is in the mbtiles - ie the default reference point as well as the default full time period.

[stackTom]

There are two messages (rendering, and recoloring). Rendering happens very quickly and is often not seen if you have a fast computer. It means knowing which new points have been rendered with a zoom in/out or panning the map (as not all points are always rendered due to performance issues).

Recoloring just means waiting for data from the postgresql database to come down over the internet. So recoloring is basically equivalent to "downloading". There are no more steps to the process significant enough to include in a loading screen. There are minor ones like "sending data to postgresql server to recolor" but this takes milliseconds always. It's not worth it to make a loading screen for this as it will never be seen from how fast it happens.

[falkamelung]

Yes, don't recolor if we are back to the full period. It will give confidence if when going back to the original state it behaves the same as previously.

OK, I sort-of understand. So every time something is selected differently from the original ingest (startDate, referencePoint) we need to re-download.

I think my hope thoughout all this was that we can buffer more data in the local memory, or something similar Anyway, I just wanted to make sure that we don't miss out on anything. So let's leave it at this with the speed/recoloring.

[stackTom]

I will work on making it not have to download data/recolor when it's back to the original dates and we are using the default reference point.

Not sure how to buffer more data in the browser to prevent redownloads. It is impossible to predict what points a user has in view, what dates they want, etc. So even if I were to create a cache by downloading data ahead of time, in the background, there is a high probability that it won't be the data we need at the moment...

[falkamelung]

Hmmm.... If the buffering is a possibbilty in principle, I can see multiple options. Not sure they are possible:

• buffering of full dataset if the file size is below a certain limit (e.g. 1GB)
• button for buffering the full dataset current window (as long as it is below a certain size)
• button to draw a rectangle for buffering (also keep size limit)
• buffering to a given zoom level

The datasets we are currently looking at are very big. For other applications they are smaller. We probably would make sure that datasets where the recoloring is important stay below a given size.

[stackTom]

This would involve substantial development, and I'm not sure if the speed up would be worth it or whether there would even be a significant speed up. I have a rough idea in mind but it would entail the browser doing more calculations. So the download of data would be gone but now the browser has to do more calculations. There is always trade off between calculations and memory usage in any program.

I'm not sure if it would be worth it especially since recoloring has gotten quite fast. And will get even better once this issue in the first post as well as https://github.com/geodesymiami/insarmaps/issues/109 are fixed.

[stackTom]

Fixed with https://github.com/geodesymiami/insarmaps/commit/b25929f55fa7ba9c64813aa84199ddcc3d7542d7

[stackTom]

Also with https://github.com/geodesymiami/insarmaps/commit/92cdd6068ae62c295b106356e3d10d56deb8770a