ThinkGeo.com    |     Documentation    |     Premium Support

Changed behavior of LevelTipsChanged

#1

Hi,

After upgrading to 14.3 we noticed that MapTools.PanZoomBar.LevelTipsChanged event is now raised in situations where it was not raised with 14.2.2 version. This behavior is seen when maps IsManipulationEnabled is set to true.

With new version LevelTipsChanged is raised e.g when map is only tapped from touchscreen without actually zooming anything (this did not happen on earlier versions). Also it seems that zooming (pinch) from touchscreen causes flood of these events (with slow pinch hundreds of events) but with earlier version only two events were fired (also new version raises events even when zoom level does not actually change which older version did not do).

Is this change of behavior intentional ?

Br, Simo

#2

Hi Simo,

This is a bug, it is verified and fixed in the latest beta (14.4.0-beta036). Please pull the latest and have another try.

Thanks,
Ben

#3

Hi,

Yes, seems to work correctly with latest beta version. Is there any workaround to fix this with 14.3

I also noticed changed behavior when zooming with touchscreen. Zoom level does not snap to closest level anymore (like it does with zoom buttons/mouse). Is there some way to force snapping also with touchscreen ?

Br, Simo

#4

Hi Simo,

  1. You can create a custom PanZoomBarMapTool like following:

    class MyPanZoomBarMapTool : PanZoomBarMapTool
 {
   int currentLevel = 0;
   string currentLevelTip = string.Empty;

 protected override string OnLevelTipsChanged(string levelTip, int level)
 {
     if (level != currentLevel)
     {
         // only raise the event when necessary
         currentLevel = level;
         currentLevelTip = levelTip;
         return base.OnLevelTipsChanged(levelTip, level);
     }
     return currentLevelTip;
 }
}

// ......
// disable the default PanZoomBar
MapView.MapTools.PanZoomBar.IsEnabled = false;
// add the new one to the map
MapView.MapTools.Add(new MyPanZoomBarMapTool());

  2. You can manually call mapView.ZoomTo() to snap after displaying, like following:

    MapView.OverlaysDrawn += MapView_OverlaysDrawn;
// ......

private void MapView_OverlaysDrawn(object sender, OverlaysDrawnMapViewEventArgs e)
{
   var snapedIndex = MapUtil.GetSnappedZoomLevelIndex(MapView.CurrentScale,   MapView.ZoomScales, 0, double.MaxValue);
   var snappedScale = MapView.ZoomScales[snapedIndex];

 _ = MapView.ZoomToAsync(snappedScale);
}

Thanks,
Ben

#5

Hi,

Thanks, for examples.

I also noticed changed behavior when zooming the map with MultiTile overlay (it has one layer containing lot’s of features with clustering). Earlier when zooming the map overlay was drawn at once with new zoom level (clusters from old level were cleared before drawing new one).

Now with 14.3 it seems that first everything is drawn (tile by tile) for new level (on top of old level) and finally old level is cleared. This causes that changing the zoom level does not look as smooth as it was earlier. See the attached videos from 14.2.2 and 14.3.Videos.zip (3.9 MB) With more features update is even slower than on videos.

Is this somehow related to new animation settings or changes on zooming ? It feels like that earlier e.g while zooming out all tiles on the edge of map were visible on the display after all tiles were drawn (seen on video from 14.2.2). Now it seems that each tile is visible after it is drawn (tiles on edges become visible one by one).

Is there anyway to achieve similar (or smoother) transition between zoom levels ?

Br,Simo

BTW, Similar change on behavior can be seen with HowDol sample “Display Cluster Points” if overlay is changed to MultiTile.

#6

Hi Simo,

This change in v14.3 was intentional to make the overlay feel more responsive. In v14.2, a MultiTile overlay behaved like a single‐tile one: it waited until every new tile was rendered before displaying the tiles on the map. In v14.3, each tile is drawn as soon as it’s ready, and we only clear the old tiles once all the new ones have finished. That delivers faster, more incremental updates—at the cost of briefly showing old tiles underneath if your overlay has a transparent background.

If you prefer the “all-at-once” refresh you saw in v14.2, just switch your overlay to SingleTile . It renders the entire set in one pass, giving you the same smooth transition and even better performance (as it fetches the data / do the rendering only once).

Let me know if there’s some reason you want “all-at-once” refresh but don’t want to use SingleTile.

Thanks,
Ben

#7

Hi,

Thanks for the info.

I was just curious to know the reason behind this changed behavior. We switch to SingleTile to get same smooth transition as earlier.

Br, Simo

#8

I see, sounds good. Just let us know if you have any more questions.