[BUG] map in app loads extremely slow about immich

[shenlong-tanwen]

@alextran1502 I think this issue is worth investigating more in depth. The tile server performs perfectly well on the web client, and I also have this same issue in the app (while pulling up the map view in my mobile browser works just fine).

I'm thinking of getting together a POC in the near future with maplibre-gl flutter library instead of the currently used flutter_map and I hope it performs better than the current implementation. Let's keep this issue opened until the performance issue is addressed.

[alextran1502]

I guess this is the limitation of the tile server and also based on the location where you are using the app. I don't think there is anything that we can do about this

[bo0tzz]

@alextran1502 I think this issue is worth investigating more in depth. The tile server performs perfectly well on the web client, and I also have this same issue in the app (while pulling up the map view in my mobile browser works just fine).

[aisbergde]

I confirm that loading the map takes very long, depending on the count of items. In the browser the map loads much faster, than in the app. And I like the map in the browser much more, which shows numbers. The heat map is "uggly". And because I am color handicapped, the used colors are not well selected. Maybe to create this heat map from ten thousands items is not optimal. Why we can't get the same nice map as in the web browser?

[shenlong-tanwen]

The heat map is "uggly". And because I am color handicapped, the used colors are not well selected. Maybe to create this heat map from ten thousands items is not optimal. Why we can't get the same nice map as in the web browser?

Apologies for the inconvenience, the colors certainly can be updated for better accessibility. Can you open a new issue to update the colors of the heat-map? Can you also create a FR to provide an option to show clusters instead of the heat-map in the mobile app? We can discuss if we can replace the heat-map with the clusters or provide clusters as an additional option in the discussion thread. Let's keep this issue scoped to the performance of rendering the map in the mobile app which is certainly not related to the heat map generation ':)

[aisbergde]

For me it looks like the required time to render the map is somehow proportional to the items count. That's why my idea was, that it could be related to the heat map: If the map rendering is based on getting all coordinates for all items first, then it takes some time. If the map would be generated based on clustered blocks, much less data would be need. The work could be done in the backend on the server. Depending on implemtation, the database engine could do the work and just deliver the result for clusters, which should be faster.

I don't know, how it is implemented. I only think about, how I would do. And because my main business is Business Intelligence (databases, reporting, ...), I normally try to solve performance issues in the backend.

But if it would be a backend issue, then the issue should happen also in the web browser. But there it is fast. That's why I think, it's a frontend issue, or it is related to a different approach on mobile and in the map, getting different data (detailed per item versus per cluster). And because the visible difference is heat map versus cluster, my idea was, that the heat map could be the issue. But I could be wrong. Just wanted to explain, why I wrote what I wrote.