-
Notifications
You must be signed in to change notification settings - Fork 1.3k
refs #6779: mobile SDK style transition options #7711
Conversation
@incanus, thanks for your PR! By analyzing this pull request, we identified @1ec5, @boundsj and @friedbunny to be potential reviewers. |
- (void)setTransitionDuration:(NSTimeInterval)duration; | ||
- (NSTimeInterval)transitionDuration; | ||
- (void)setTransitionDelay:(NSTimeInterval)delay; | ||
- (NSTimeInterval)transitionDelay; |
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.
These options should be exposed as properties.
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.
@@ -7,4 +7,7 @@ | |||
/// Converts from a duration in seconds to a duration object usable in mbgl. | |||
mbgl::Duration MGLDurationInSeconds(NSTimeInterval duration); | |||
|
|||
/// Converts from an mbgl duration object to a duration in seconds. | |||
NSTimeInterval MGLSecondsFromDuration(mbgl::Duration duration); |
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.
MGLTimeIntervalFromDuration()
would make the return type clearer, presuming that an NSTimeInterval
is always measured in seconds (which is the case).
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.
Then should we not also rename MGLDurationInSeconds()
to MGLDurationFromTimeInterval()
?
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.
MGLDurationInSecondsFromTimeInterval()
, actually. mbgl::Duration
can be expressed in many units; seconds is the one we’ve chosen to use for consistency with NSTimeInterval
, but other parts of mbgl use milliseconds instead.
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.
Right, took me a while to figure that out, but true. Do you think it's worth adding an assertion or other check here that it remains in seconds in this part of the code?
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.
No, I don’t think that’s an issue with std::chrono::duration
or mbgl::Duration
(which is actually in nanoseconds, my bad). MGLDurationInSeconds()
performs a duration_cast
to ensure that the output has the right quantity (if not the same unit as the input).
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.
mbgl::Duration
is similar to NSTimeInterval
in the sense that the unit is fixed and built into the type. You can't have one mbgl::Duration
representing a duration "in seconds" and another representing a duration "in milliseconds". The actual unit is defined by std::chrono::steady_clock
and I'm not sure that it's invariant across platforms or standard library implementations. But it is fixed at compile time.
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.
|
||
- (void)setTransitionDuration:(NSTimeInterval)duration | ||
{ | ||
mbgl::style::TransitionOptions transitionOptions = self.mapView.mbglMap->getTransitionOptions(); |
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.
auto
is typically used in situations like this to avoid repetition.
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'm going to bring this to Android too, for parity. |
Can you file a separate issue about that? Depending on how systematic that issue is, we may want to hold off on a delay option until it’s fixed. There’s an outstanding PR to support realistic color interpolation in style properties: #6442. (#6724 and #6721 track the SDK frontend to this support.) Does the style specification need something similar for global transitions? |
👉 #7720 |
@cammace Any chance you could review the Android part of this? I'm also all 👂 when it comes to possible testing ideas. I checked out some other tests for animated components like camera changes, but from what I could see, none of them actually try a non-zero duration? |
@@ -1226,7 +1226,7 @@ - (void)handlePanGesture:(UIPanGestureRecognizer *)pan | |||
if (drift) | |||
{ | |||
CGPoint offset = CGPointMake(velocity.x * self.decelerationRate / 4, velocity.y * self.decelerationRate / 4); | |||
_mbglMap->moveBy({ offset.x, offset.y }, MGLDurationInSeconds(self.decelerationRate)); | |||
_mbglMap->moveBy({ offset.x, offset.y }, MGLDurationInSecondsFromTimeInterval(self.decelerationRate)); |
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.
You’ll need to make corresponding changes to the macOS implementation of MGLMapView.
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.
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.
The iOS and macOS changes look good. Some suggested wording below. Don’t forget to update the iOS and macOS changelogs.
#pragma mark Managing a Style’s Transition Options | ||
|
||
/** | ||
Animation duration for style changes. Defaults to zero (instant change). |
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.
What kind of changes can be animated? Just style layer attributes?
The duration (in seconds) to animate any changes to layout or paint attributes in the style.
By default, this property is set to 0 seconds, so any changes take effect without animation.
@property (nonatomic) NSTimeInterval transitionDuration; | ||
|
||
/** | ||
Animation delay for style changes. Defaults to zero (instant change). |
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.
The amount of time (in seconds) to wait before animating any changes to layout or paint attributes in the style.
By default, this property is set to 0 seconds, so any changes begin to animate immediately.
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.
Don’t forget to also update the android changelog :)
#pragma mark Managing a Style’s Transition Options | ||
|
||
/** | ||
The duration in seconds to animate any changes to the style URL or to layout and paint attributes. |
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.
Huh, I overlooked the fact that changes to the style URL can also be animated. That’s kind of awkward, since changing the style URL means swapping one MGLStyle object for another.
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.
Actually, #5665 makes it sound like we don’t have “diff and patch” functionality in mbgl yet. Has the situation changed since July?
Starting to plumb the core transition options for the style out to iOS and eventually Android.
Duration works fine, but delay causes a crash within
Interpolator<Color>
due toassert
in theColor
constructor failing, in my case due to negative RGBA values (going from gray to black buildings). Delay probably isn't factored in when continuing to subtract below zero. This may be a core bug.Fixes #6779.