-
-
Notifications
You must be signed in to change notification settings - Fork 862
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: migrate Point<double>
to Offset
internally
#1996
Conversation
mapController.camera.pointToLatLng
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some things I would be even more heavy handed/breaking on. I would be in favour of implemented deprecated methods just to ease the transition for external users, but I think we need to be more thorough.
Is there any reason for keeping Bounds
using Point
?
lib/src/layer/shared/layer_interactivity/internal_hit_detectable.dart
Outdated
Show resolved
Hide resolved
Point<double>
to Offset
internally
Yes, I have only migrated the Point interface methods in |
Co-authored-by: Luka S <github@jaffaketchup.dev>
…le.dart Co-authored-by: Luka S <github@jaffaketchup.dev>
most methods on integer bounds are not used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple things left, mostly nits.
lib/src/layer/shared/layer_interactivity/internal_hit_detectable.dart
Outdated
Show resolved
Hide resolved
Co-authored-by: Luka S <github@jaffaketchup.dev>
Co-authored-by: Luka S <github@jaffaketchup.dev>
Co-authored-by: Luka S <github@jaffaketchup.dev>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🎉. Performance seems to have improved (about 0.2ms on home page example app, 0.3-0.4ms on basic polygon page, untested others), enough to actually make things feel slightly smoother (but maybe that's just a placebo). Don't notice any bugs, and code looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like these changes. 😄
Maybe a feature release would be good before merging breaking changes?
Edit: I wouldn't be sad if we'd not use records here, but pr is fine as is too. (:
final (minx, miny) =
transformation.transform(b.min.dx, b.min.dy, zoomScale);
final (maxx, maxy) =
transformation.transform(b.max.dx, b.max.dy, zoomScale);
i like that for future changes. I want to avoid creeping scope on this PR too much for now. we could wait to release for more changes |
This will yield significant performance benefits due to a reduction in casting. This likely breaks the external API but it is worth it
Migrations:
Point<double>
->Offset
orSize
Bounds<double>
->Rect
Bounds<int>
-> (rename and marked internal)IntegerBounds
maybe fixes #1769 (it is not a full migration, as there are still record types (they are okay in certain conditions honestly, especially as an interface between public apis), but it does fix a TON of issues with math.Point, which is much slower than the difference between Objects and Records)
there is a modest 7% performance boost in the polygon and polyline tests in both the UI and Raster threads in my debug mode profiling. i expect other layers to benefit and more performance boost in ideal situations