Path simplification

[p-lr]

@Nohus
I'm creating this discussion as it's a better place to keep you updated about my progress.

• I think I'll further reduce epsilon to 1 pixel at scale 1, so that the path simplification becomes even less noticeable.
  Even with this reduction, one of the path in the demo sees a reduction in the number of its points of 93% when fully zoomed out.

• I've added a way in the path api to disable path simplification.

[Nohus]

I wonder if instead of a way of disabling it, there could just be an epsilon parameter, which turns it off when it's at 0? That way you can not only disable it if needed, but also fine tune for your liking. There is a risk of making it feel complicated though, if a library user doesn't understand the technicalities of this.

[p-lr]

This is a good idea. Will do the change.

[p-lr]

In order to allow for customisation and still be understandable, what about having a simplify parameter? The default value would be 1f, and the documentation would state that a value of 0f effectively disables path simplification.

[Nohus]

That makes sense. I think the KDoc could explain what it actually is, while keeping it simple at a glance.

[p-lr]

Added simplify parameter as Float.
Found and fixed a bug: the path width was set in pixels, not dp. For example, the default width was 8.dp. The actual path width was then 8 px.
Now, the default is 4.dp

[Nohus]

I didn't even notice because Google Maps Compose uses pixels for path widths, so when I migrated my project to MapCompose all my path widths were correct as they were.

Now I had to modify them to use Dp, but it makes sense. : )

[p-lr]

This is actually a bit embarrassing, because this bug fix dramatically changes paths width. I'll make a special comment in the release notes.

[Nohus]

Ah, yeah if I wasn't in this conversation and just updated the library I would be quite confused why my paths are suddenly much thicker. Definitely worth noting in release notes.

[p-lr]

Added cap parameter to addPath and updatePath apis. Initially, I added startCap and endCap parameters, only to realize that the drawPath api does not support having different cap styles for both ends...
So for instance I fallback to having a single cap parameter. Possible values are:

• Butt: The stroke ends with the path, and does not project beyond it.
• Round: The stroke projects out as a semicircle, with the center at the end of the path.
• Square: The stroke projects out as a square, with the center at the end of the path.

This should be the last bit before releasing a new version.

[Nohus]

I've tested it, works great here.
For having different styles on ends, you could change the paint for the first and last segment of the path (draw them separately), but it's probably not worth it.

[p-lr]

Great, thanks for taking the time to test it.
You're right, it could be possible but probably not worth it.

[p-lr]

The version 2.7.0 is released and contains all changes discussed above.

[Nohus]

Thank you, works fine!

[p-lr]

I just noticed that setting strokeJoin = Paint.Join.ROUND on the Paint produces smoother paths. When zooming out and when path simplification kicks-in, sometimes a sharp angle becomes noticeable. Using round join removes that effect.
I'm thinking of making that default and also add join as api parameter. Or maybe don't add any parameter.

With round join:

Without: