WPF: how to control viewpoint change on MapView resize?

[ViktorSafar]

I have a WPF app with a Grid with 2 columns.

            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="auto" />
                <ColumnDefinition Width="*" />
            </Grid.ColumnDefinitions>

In column 1 there is a user control (WorkContentUC) that has variable content, and is actually collapsed at startup.

In column 2 there is a user control (MapUC) that contains a MapView.

When WorkContentUC.Visibility is changed to Visible, the MapView changes size and re-centers with respect to the new size.

My problem is that the re-centering is "instant" and the map appears to jump. How do I "slow it down"?

I have added a handler to MapView.SizeChanged to SetViewpointAsync with a duration of 3 seconds but it does not have any effect:

MainMapView.SizeChanged += HandleMapViewSizeChanged;
...
private async void HandleMapViewSizeChanged(object sender, SizeChangedEventArgs e)
{
	var currentViewpoint = MainMapView.GetCurrentViewpoint(ViewpointType.CenterAndScale);
	if (currentViewpoint is null)
	{
		return;
	}

	await MainMapView.SetViewpointAsync(currentViewpoint, TimeSpan.FromSeconds(3));
}

[dotMorten_esri]

I'm not entirely sure what you're hoping to accomplish, but looking at the above code, that event fires _after_ the map has resized, so the viewpoint you're getting is the new viewpoint. That means setting the viewpoint to something it already is likely won't have any effect.
There's also some resize-throttling going on, so if you for instance resize the window continuously, it slows down the mapview update a little until you stop resizing to reduce resource use. That throttling might make it a little harder to accomplish handling changes during resizes.

[ViktorSafar]

I try to rephrase the problem. When the MapView resizes, the viewpoint changes instantly. From user perspective, this looks like the map jumps. Can the viewpoint change, caused by the change of MapView size, be slowed down?

[ViktorSafar]

I try to rephrase the problem. When the MapView resizes, the viewpoint changes instantly. From user perspective, this looks like the map jumps. Can the viewpoint change, caused by the change of MapView size, be slowed down?

[dotMorten_esri]

I'm still a little confused what the expectation is here. If the mapview resizes, the view that is displayed has to change with it to expand/contract the visible area along with the resize.
Do you have an example / screen recording or something that behaves the way you're looking for to help me understand what you're looking for?

[ViktorSafar]

Yes, it has to change. But can this jumping effect be somehow prevented?

https://youtu.be/HwwroV6jLbw

[GKmieliauskas]

Hi,

If I understand correctly, you are talking about the AnimationCurve and duration which are available when you set viewpoint from code. For internal calls of setting viewpoint there is no such interaction parameters, I think.

[dotMorten_esri · Accepted solution]

Thanks for the video. I see what you're saying, and how a smoother transition might be nice.

The biggest problem I foresee to solving this though is we wouldn't actually know in which direction to animate. If the panel you're opening or closing is on the right instead, the direction would be opposite, but MapView control would have no knowledge beyond its size about what direction it got pushed in.
So there's actually two jumps here. The panel opening pushes the mapview to the right, making it jump over, and then there's a resize that will clip the mapview and it'll restore its center location to this new location.

We do some throttling on resize so we don't actually immediately resize the mapview - this is mostly to handle drag and animated resizes, where each resize would flood the GPU with re-building the render texture, but of course the downside to that is these immediate single-resizes which then have a slight delay in updating and you get the "double-jump". Unfortunately the MapView control has no knowledge of what is causing a resize, just that a resize occurs, so we can't even special-case it.