-
Notifications
You must be signed in to change notification settings - Fork 131
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
[viewannotation] optimize cameraForAnnotations api MAPSAND-577 #1861
Conversation
b4eda9b
to
66b343f
Compare
84fe297
to
b9e01a4
Compare
sdk/src/test/java/com/mapbox/maps/shadows/ShadowCoordinateBounds.java
Outdated
Show resolved
Hide resolved
var west: Pair<ViewAnnotationOptions, Rect?>? = null | ||
var south: Pair<ViewAnnotationOptions, Rect?>? = null | ||
|
||
while (!isCorrectBound) { |
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.
how many iteration can be here in worst case? can it be forever loop?
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.
Can't be a forever loop, the worst case iteration is 2 loops.
Initially, we are getting innerBounds cameraOption
before while loop, then the next iteration is checking if it needs extra paddings. All other nullability checks have already been tested.
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.
We discovered a case where this can loop forever on iOS - with certain combination of camera state/map size/view annotations there might be one pair(view annotation options & rect) to be e.g. southern-most for a particular zoom level, and for another zoom level the different pair can become southern-most.
Potentially this code is also susceptible to the same scenario, worthwhile to double check. @maios is leading the investigation of this on iOS.
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'd probably removed the loop, extracted the code calculating cameraOptionForCoordinates
and explicitly called it twice to avoid any risks.
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.
Yeah, make sense. although I couldn't reproduce the issue on android with the same setup. I will try to loop it with a counter and that would be our maximum tries to adjust the bounds.
I can see that this might not provide correct bounds for all cases, but we have discussed this with gl-native to reiterate over framing implementation.
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.
added ticket to track this issue.
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.
@ank27 at the same time why do we need a loop for two iterations? What about extracting to function and calling twice? Code will be more clear and not additional variables involved
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.
In case we need to have more iteration in the future to have better bounds. but that's debatable.
btw why can't we use loop though?
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.
@ank27 I was thinking that the loop is not needed if we know that we have fixed and limited number (== 2) of iterations to calculate the bounds. Now it seems that it's not - and I'm actually ok with having the loop with counter which can be controlled. The question is do we want it to be 2 or some larger value to be almost certain that the bounds will be correctly calculated.
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.
2 iteration i found good for the cases i have tested, but i can't be sure of all edge-cases (for eg. pitched map and with bearing). so i am not 100% sure about fixed number.
The question is do we want it to be 2 or some larger value to be almost certain that the bounds will be correctly calculated.
cut a ticket to look more into finding correct calculations for all cases.
fb369ad
to
91cc451
Compare
8a09463
to
f16074a
Compare
boundsCounter++ | ||
isCorrectBound = true | ||
viewAnnotationOptions.forEach { options -> | ||
val frame = getViewAnnotationOptionsFrame(options) ?: Rect(0, 0, 0, 0) |
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.
nit : make getViewAnnotationOptionsFrame
return nun-nullable value? Options are non-null
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.
getViewAnnotationOptionsFrame
is a separate internal function, that can be used in some other calculations in future. making it non-nullable will force us to return Rect(0,0,0,0)
in case of no viewannotation present, which might not be best in some scenario.
// we run the loop twice to adjust bounds correctly to fit all the annotations. | ||
var boundsCounter = 1 | ||
while (!isCorrectBound && boundsCounter <= MAX_ADJUST_BOUNDS_COUNTER) { | ||
val zoom = cameraOptionForCoordinates.zoom |
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.
nit : declare val out of loop above
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.
ohh wait, it's used inside while loop only, so I will keep it here.
@ank27 can you please rebase it? seems to be pretty outdated |
sdk/src/test/java/com/mapbox/maps/ViewAnnotationManagerAddTest.kt
Outdated
Show resolved
Hide resolved
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 with several nits
2ad7244
to
eea6a1d
Compare
65aba12
to
c3d5a6b
Compare
* optimize cameraforannotations api * update cameraforannotation implementation * update apis to adjust paddings * update cameraforannotation implementation * address review comments * limit bounds calculation loop * address review comments * update changelog
#1889) * optimize cameraforannotations api * update cameraforannotation implementation * update apis to adjust paddings * update cameraforannotation implementation * address review comments * limit bounds calculation loop * address review comments * update changelog
* use unix time for unique version code * publish_testapp_playstore
Summary of changes
Currently
ViewAnnotationManager.cameraForCoordinate
doesn't work as expected when multiple viewannotations have different width and height.This pr improves the api implementation by calculating correct bounds taken by
ViewAnnotationOptions
's width and height using different Projections api.before.mov
after.mov
User impact (optional)
Pull request checklist:
@JvmOverloads
,@file:JvmName
, etc).make update-api
to update generated api files, if there's public API changes, otherwise theverify-api-*
CI steps might fail.check changelog
CI step will fail.v10.[version]
release branch fix / enhancement, merge it tomain
firstly and then port tov10.[version]
release branch.Fixes: < Link to related issues that will be fixed by this pull request, if they exist >
PRs must be submitted under the terms of our Contributor License Agreement CLA.