Polyline segments visibly overlap with alpha < 1

[tomtaylor]

If you draw a MGLPolyline with an alpha < 1, the colour multiplies where segments overlap and it looks a little strange.

[1ec5]

Compounding the effect, each line segment appears to have a round line cap and a square line cap.

[incanus]

Ah, at first I thought this was a factor of line joins, which place a dot at the junction, but it does look like caps instead.

Related: #1734

[tomtaylor]

@incanus: Does this look like a relatively easy fix? It's one of two outstanding bugs that are preventing me shipping an app on MapboxGL (modifying the logo and attribution buttons being the other), and it'd be amazing if they could get rolled into the next release. Even just an ETA would be helpful - thanks! Let me know if there's a better channel for this.

[incanus]

@jfirebaugh @ansis Do you have a sense how tough this fix is?

[incanus]

I think we can experiment with the line joins/caps here to fix this without adverse effects. I will check it out.

[ansis]

@incanus see mapbox/mapbox-gl-js#794 (comment)

The quickest workaround is to use "line-join": "miter", which is the default line join type.

[incanus]

Test line is 0.5 alpha, 10.0 line width, [UIColor blueColor].

Line join for polyline annotations is set here:

mapbox-gl-native/src/mbgl/map/map_context.cpp

Lines 214 to 217 in 295ea08

	// apply line layout properties to bucket
	if (shapeStyle.is<LineProperties>()) {
	shapeBucket->layout.set(PropertyKey::LineJoin, ConstantFunction<JoinType>(JoinType::Round));
	}

Current (round):

Reverting to the default of miter looks like this:

So, the join problems are fixed, but the line is jagged, especially at sharp turns. This was the main reason I used round in the first place.

Just for completeness, here's bevel:

Looks better, but still problematic on sharp corners.

Lastly, flipbevel, whatever that is:

[incanus]

Experimenting with line-miter-limit.

[ansis]

hmm, it looks like there are some tessellation bugs.

flipbevel is just for internal use. Bevels are drawn two different ways depending on the sharpness of the corner.

[incanus]

@tomtaylor Based on this, it doesn't appear to be a trivial fix. Would it help if we work a bit on #1734 and expose settings like the line join, so you can choose based on your data? Maybe you won't have sharp corners and a miter join would look ok?

[incanus]

Here's a good patch for testing this by the way, using the default test shape of the hike up in northern Washington:

diff --git a/ios/app/MBXViewController.mm b/ios/app/MBXViewController.mm
index 0024582..a19f8bd 100644
--- a/ios/app/MBXViewController.mm
+++ b/ios/app/MBXViewController.mm
@@ -347,12 +347,12 @@ mbgl::Settings_NSUserDefaults *settings = nullptr;

 - (CGFloat)mapView:(__unused MGLMapView *)mapView alphaForShapeAnnotation:(MGLShape *)annotation
 {
-    return ([annotation isKindOfClass:[MGLPolygon class]] ? 0.5 : 1.0);
+    return ([annotation isKindOfClass:[MGLPolygon class]] ? 0.5 : 0.5);
 }

 - (UIColor *)mapView:(__unused MGLMapView *)mapView strokeColorForShapeAnnotation:(MGLShape *)annotation
 {
-    return ([annotation isKindOfClass:[MGLPolyline class]] ? [UIColor purpleColor] : [UIColor blackColor]);
+    return ([annotation isKindOfClass:[MGLPolyline class]] ? [UIColor blueColor] : [UIColor blackColor]);
 }

 - (UIColor *)mapView:(__unused MGLMapView *)mapView fillColorForPolygonAnnotation:(__unused MGLPolygon *)annotation
@@ -360,6 +360,11 @@ mbgl::Settings_NSUserDefaults *settings = nullptr;
     return (annotation.pointCount > 3 ? [UIColor greenColor] : [UIColor redColor]);
 }

+- (CGFloat)mapView:(__unused MGLMapView * __nonnull)mapView lineWidthForPolylineAnnotation:(__unused MGLPolyline * __nonnull)annotation
+{
+    return 10;
+}
+
 - (void)mapView:(__unused MGLMapView *)mapView didChangeUserTrackingMode:(MGLUserTrackingMode)mode animated:(__unused BOOL)animated
 {
     UIImage *newButtonImage;
diff --git a/src/mbgl/map/map_context.cpp b/src/mbgl/map/map_context.cpp
index fa06a42..64d81a3 100644
--- a/src/mbgl/map/map_context.cpp
+++ b/src/mbgl/map/map_context.cpp
@@ -213,7 +213,8 @@ void MapContext::updateAnnotationTiles(const std::unordered_set<TileID, TileID::

             // apply line layout properties to bucket
             if (shapeStyle.is<LineProperties>()) {
-                shapeBucket->layout.set(PropertyKey::LineJoin, ConstantFunction<JoinType>(JoinType::Round));
+                shapeBucket->layout.set(PropertyKey::LineJoin, ConstantFunction<JoinType>(JoinType::Miter));
+                shapeBucket->layout.set(PropertyKey::LineMiterLimit, ConstantFunction<float>(10));
             }

             // connect layer to bucket

[mb12]

@ansis and @incanus Tesselation bug/line smudginess is very similar to what I've seen on Android devices (consistently reproducible on Samsung Nexus S). I am referring to the following issue. Lines on some Android device show the kind of smudginess that is included in the screenshots above. Smudginess gets worse upon pan/scroll.

#1702

[tomtaylor]

Hi @incanus and co, thanks a lot for looking at this. Yeah, I think I'm unlikely to have sharp corners or overlaps, so exposing some more options would help enough that I could get this out the door. Much appreciated.

[incanus]

@tomtaylor We are looking at this directly in #1839 and are hoping to roll it into the next dev build, ideally today, with the milestone build later this week.

[tomtaylor]

@incanus great, thanks!

[incanus]

@tomtaylor If I were to roll a custom build for you, would you be able to try it out? What are you using for install method? #1839 is looking pretty good in our testing.

[tomtaylor]

@incanus sure thing. I'm using CocoaPods, currently pointing at the podspec on master. If you could provide me with a different podspec URL, I could try that?

[incanus]

@tomtaylor Give this one a shot:

https://github.com/raw/mapbox/mapbox-gl-native/1771-shape-tolerance/ios/MapboxGL.podspec

[tomtaylor]

@incanus that looks identical to me - no changes from the original issue. Are you sure that's pointing to the correct build?

[incanus]

Oh, shoot, I forget to combine the simplification changes (included) with #1839 (not included). Sorry to waste your time — one sec.

[incanus]

Ok @tomtaylor, trash your Pods and pod update with the same URL and it should grab a different build. This one has the line join improvements from #1839 and a tweak to the polygon simplification as well to make them less pronounced.

[tomtaylor]

Thanks, that works. (I had to flush ~/Library/Caches/CocoaPods too, just FYI.)

It's almost perfect, but there's a couple of little join glitches still. Much better than it was. They usually disappear when you zoom in 1 or 2 levels. Maybe increase the simplification a bit further?

[incanus]

I'm wary to tweak the simplification for the specific case in light of affecting the general case. I also don't really want to expose simplification settings to the user as this gets complex.

FWIW 888ae5e and 03c4ed7 just landed in master, so tonight's regular build will have the same effect as the custom build from #1771 (comment).

[tomtaylor]

Sure, understood. Thanks a lot - when the sprite customisation has landed I'll be able to ship this app.

[incanus]

That just got merged — expect a build shortly.

[incanus]

Going to move this off of the b3 milestone as we've made improvements here. We'll keep working on this — the end goal is zero overlap.

[picciano]

This seems mostly resolved, but we are still seeing the occasional overlap, especially in angles < 90°.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.