ThinkGeo.com    |     Documentation    |     Premium Support

14.5 and DrawingQuality

#1

Hi,

It seems that handling of DrawingQuality has been updated to 14.5 to be overlay specific. With previous versions we have had combinations like:

Overlay - HighSpeed
InMemoryFeatureLayer - HighSpeed
InMemoryFeatureLayer - Default

Is it now so that we need to split layers to different overlays if layers need to have different quality ?

Also I noticed that with new 14.5 HighSpeed quality is not the same compared to previous version. Is this correct observation ? Here is an example where on the left 14.4.5 both overlay/layer are HighSpeed and on the right 14.5 with overlay as HighSpeed.

image

It can be seen that text and outline quality is worse in 14.5.

Br, Simo

#2

Hi Simo,

You’re right.

  1. Skia (the rendering engine used by ThinkGeo) has moved away from the concept of High/Medium/Low quality levels, so we updated our API to align with that direction. The main reason is that a single “HighQuality” setting cannot produce optimal results across different types of maps.

  2. Instead, we now provide more fine-grained control over rendering quality:

  • For Vector rendering (your case): you can use TileOverlay.RenderingOptions to control anti-aliasing for Image, Vector, and Text individually.
  • For Map Tiles you can adjust the resampling algorithm.

By default, DrawingQuality.Standard enables anti-aliasing for Vector and Text, but disables it for Image. When set to HighSpeed , anti-aliasing is also disabled for Text and Vector, which reduces label quality—that’s the trade-off for better performance. In that sense, the newer behavior is more accurate and predictable. We’d recommend you to just leave it to DrawingQuality.Standard which should be good for most of the cases.

If you’re interested, you can find more details here:
https://docs.thinkgeo.com/products/thinkgeo-core/thinkgeo-raster-sampling-matrix/

Thanks,
Ben

#3

Hi,

Not sure if it is related to this quality but were are experiencing weird issue when integrating to 14.5 (earlier version 14.4.5). We have an LayerOverlay with InMemoryFeatureLayer.

In that InMemoryLayer we use PointStyle(GeoImage image) as DefaultPointStyle then we have just one point on that layer. Earlier this has been working without any issues but now with with 14.5 in some environments only one fourth of that GeoImage is drawn to map (on others environments image is drawn correctly).

Do you know what could cause this kind of inconsistent GeoImage drawing with 14.5 ?

Br, Simo

#4

Hi Simo,

It has been fixed in 14.5.0-beta021.

You didn’t mention a high-DPI environment, but based on our investigation, we suspect this issue is related to high-DPI rendering (more specifically, the canvas ScaleFactor). In some cases, when an image marker is drawn near a tile boundary, the drawing query margin was not scaled correctly, so part of the symbol could be clipped or only partially rendered.

We also believe this issue likely existed in 14.4.* as well, but it was harder to reproduce there because it only appears when several conditions line up, such as display scaling, symbol size, and the feature position relative to the tile boundary.

Please pull the latest build and give it a try. You can also set the overlay’s tile type to SingleTile, as a workaround, if that works well for your project.

Thanks,
Ben

#5

Hi,

We already have SingleTile Overlay to fix that issue near tile boundary. I was able to narrow this issue down to RotationAngle. When ever PointStyle.RotationAngle != 0 this issue happens.

It can be easily re-produced with this sample code:

    private async void MapView_Loaded(object sender, RoutedEventArgs e)
    {
        MapView = sender as MapView;
        MapView.MapUnit = GeographyUnit.Meter;

        var layer = new InMemoryFeatureLayer();
        layer.ZoomLevelSet.ZoomLevel01.DefaultPointStyle = new PointStyle(new GeoImage(@"./icon_gps_point.gif")) { RotationAngle = 90 };
        layer.ZoomLevelSet.ZoomLevel01.ApplyUntilZoomLevel = ApplyUntilZoomLevel.Level20;
        layer.InternalFeatures.Add(new Feature(new PointShape(MapView.CenterPoint.X, MapView.CenterPoint.Y)));

        var overlay = new LayerOverlay() { TileType = TileType.SingleTile };
        overlay.Layers.Add(layer);
        MapView.Overlays.Add(overlay);
        await MapView.RefreshAsync();
    }

With 14.4.5 image is drawn correctly but with 14.5 only one fourth of image is drawn. Issue seems to happen when drawing without scaling since using scaling on display (display scaling != 100% needs to be set before application is started. Changing it after application start does not cause this issue) or in PointStyle fixes the issue.

Please check if there is any workaround / possibility for hotfix to this issue.

Br, Simo

#6

Hi Simo,

Thanks for the sample. We’ve verified this is a regression introduced in v14.5 by an internal rendering optimization. It has been fixed in latest beta 14.5.0-beta022. We are currently planning to release v15.0.0 in May, mainly alongside the ThinkGeo.GisServer release. This fix will be included in that release.

You can work it around by forcing the image to go through the scaled drawing path by setting ImageScale to a value other than 1, as following:

  new PointStyle(new GeoImage(@"./icon_gps_point.gif"))
  {
      RotationAngle = 90,
      ImageScale = 1.01
  };

Thanks,
Ben

#7

Hi,

Does that scaled drawing have any negative impact to performance e.g. is it slower ?

We are updating that layer frequently so we cannot use that if it has some negative impact.

Br, Simo

#8

We did a quick local test and did not see any noticeable performance penalty. In our test with a rotated 80x80 image marker drawn 400 times in ThinkGeo.Core 14.5.1, the timings were nearly the same:

  • ScaleFactor = 1: 0.245 ms/frame vs 0.248 ms/frame
  • ScaleFactor = 2: 1.335 ms/frame vs 1.235 ms/frame
1 Like