You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Improve performance of CRS zoom & scale methods #2183
Not sure how much performance improvements we can get from this.
We have a couple of methods for projecting LatLng.
(double, double) latLngToXY(LatLng latlng, double scale);
/// Similar to [latLngToXY] but converts the XY coordinates to an [Offset].OffsetlatLngToOffset(LatLng latlng, double zoom) {
final (x, y) =latLngToXY(checkLatLng(latlng), scale(zoom));
returnOffset(x, y);
}
The most used method is latLngToOffset, that computes a scale.
/// Zoom to Scale function.doublescale(double zoom) =>256.0* math.pow(2, zoom);
The thing is that we constantly compute math.pow(2, zoom).
Given that most of the time (always?) we work on a single zoom level for all points, we could cache the latest zoom/scale values.
Something like that:
Looks like it would mean making Crs not const anymore. Which is problematic as we have default Crs constructor parameters: we need the default Crs value to be const.
Or... we create not const classes on top, that just override methods scale and zoom. As "optimized" versions.
This could be interesting to look into. I think we would need to retain const Crs classes, and layer the performance improvements on top as you said. But we would need to run a benchmark.
We'd be more than happy to accept a PR. To make your benchmark reproducible for everyone else, it might be easiest to add to benchmark/crs.dart if needed (or it might actually have everything already needed) - we can compare between commits to see performance changes.
Activity
monsieurtanuki commentedon Jan 25, 2026
And of course, the
zoommethod could be improved similarly:monsieurtanuki commentedon Jan 25, 2026
Looks like it would mean making
Crsnotconstanymore. Which is problematic as we have defaultCrsconstructor parameters: we need the defaultCrsvalue to beconst.Or... we create not
constclasses on top, that just override methodsscaleandzoom. As "optimized" versions.JaffaKetchup commentedon Mar 1, 2026
This could be interesting to look into. I think we would need to retain
constCrs classes, and layer the performance improvements on top as you said. But we would need to run a benchmark.Brijesh-gangwar commentedon Mar 17, 2026
Hi @JaffaKetchup and @monsieurtanuki is anyone already working on this? I'd love to take it up if it's still open. Thanks!
I ran a quick benchmark (median ns/op, 9 rounds):
scalesame-zoomzoomsame-scalelatLngToXYsame-zoomSummary of findings:
Happy to work on this issue with cached CRS subclasses + benchmark if this is still open!
monsieurtanuki commentedon Mar 17, 2026
Hi @Brijesh-gangwar! I haven't started anything, so feel free to benchmark!
JaffaKetchup commentedon Mar 17, 2026
Thanks for looking into this @Brijesh-gangwar !
We'd be more than happy to accept a PR. To make your benchmark reproducible for everyone else, it might be easiest to add to
benchmark/crs.dartif needed (or it might actually have everything already needed) - we can compare between commits to see performance changes.Brijesh-gangwar commentedon Mar 17, 2026
Hi @monsieurtanuki @JaffaKetchup
Ok
I will raise pr soon
[-]Performance improvement with zoom/scale[/-][+]Improve performance of CRS `zoom` & `scale` methods[/+]