Marker calulations are heavy

[TheLastGimbus]

Hi there!
For quite a time, I'm reaserching performance of flutter_map when throwing a lot of markers at it

Recently, I created a library for drawing markers on Canvas instead of widgets, and it's performing pretty well. You can check it out at dev branch (tho it uses flutter_map fork for now 😬 ) https://github.com/KanarekApp/flutter_map_fast_markers/tree/dev

But it turns out, that, even if you don't draw makers at all, the calulations that translate LatLng to X Y position on the screen are taking me to <30 fps @5k markers (when not drawing them at all!)

I copy-pasted the calulations from original markers, but I can modify them - however, I have no idea how.

Does anyone have an idea how they could be optimized?

[ibrierley]

First pondering would be to see if anyone has done similar with Leaflet.js maybe ?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[TheLastGimbus]

No dear bot, they are still heavy indeed

[aytunch]

Would using clustering help since it would decrease the number of markers being rendered on the screen?
Also if a marker is not in bounds, they are not rendered right?

[TheLastGimbus]

using clustering

Yeah I need to check it out. Tho the existing library for them looks complicated 👉 👈

not in bounds, they are not rendered right?

Yup. Tho:

the calulations that translate LatLng to X Y position on the screen are taking me to <30 fps @5k markers (when not drawing them at all!) ~Me

The caluculations that are required to know if marker is visible are heavy themselves

[ibrierley]

Thinking out loud, a few random bits....I have no idea if this makes sense yet to me, let alone others... :D. Suppose you were to take the highest tile zoom level eg 17, and calculate at first time only which level 17 tile it would be contained within (I guess be careful of markers that overlap tiles though..).

If we know a marker belongs to tile x/y/z = 1024/30/17 we should be able to calculate "fairly" fast if that tile is contained within a certain range at zoom level 12 (eg 356-358/12-14/16) or whatever (as each tile zoom just raises a power of 2)?

I'm not quite sure if it makes sense, and if it would be faster than the projection calcs, but I think you'd only need to figure it out on a tile change (ie panning within same set of tiles wouldn't need "any" recalculations at all).

Basically like a grid eliminator, similar to geohashing (eg https://www.ibm.com/docs/en/db2/11.5?topic=concepts-geohashes-geohash-covers ). I guess I'm trying to figure if a tile is sort of like a geohash (or are the tiles redherrings and could simply use geohashing ?) Something a bit like this... https://stackoverflow.com/questions/36705355/finding-geohashes-of-certain-length-within-radius-from-a-point.

Again, sorry it's a bit random, just prodding a few thoughts.

[ibrierley]

In fact, I think the tile stuff is indeed a redherring...and maybe geohashing the markers at first, then on an geohash area change, recheck them which could eliminate a lot. It's not trivial, but could be interesting, just depends if it's worth the effort to investigate. There's a dart geohash lib https://pub.dev/packages/dart_geohash...

So for example if we look at the pic on https://gis.stackexchange.com/questions/231719/calculating-optimal-geohash-precision-from-bounding-box

lets say we have a point which is geohash "gce46hy7" and we are looking roughly at a map of the UK, you may test points that start with the strings gf or gc or gb or u0, u1, u4.... so "gce46hy7" starts with "gc" so is inside and passes the test. If we have a point "eg5qr5y" it starts with "eg" which isn't part of that set, so would be excluded.

Not sure if I'm barking up the wrong tree, or if its slower, but again, I think you would only need to do a test when the map moves across to a new set of geohash strings.

Clear as mud I hope :D

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[TheLastGimbus]

Still an issue 😕

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.