Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color transparency of strokecap in polyline #1280

Closed
Ruediger34 opened this issue Feb 24, 2019 · 11 comments

Comments

@Ruediger34
Copy link

commented Feb 24, 2019

Probably a bug in the color transparency of a polyline combinated with setStrokeCap()?

Issue Type

[x] Question
[x] Bug

Description and/or steps/code to reproduce the problem

If I add a polyline to the mapview and set the color and strokecap like so:

roadPolyline.setColor(Color.parseColor("#800000FF"));
roadPolyline.getPaint().setStrokeCap(Paint.Cap.ROUND);

I would expect that the strokecap also has this "transparent" color.

Is this a bug or do I have to set the color transparency of the strokecap on another method explicitly ?

grafik

Environment

If it's a bug, version(s) of android this affects:

Probably all

Version of osmdroid the issue relates to:

6.0.3

@monsieurtanuki

This comment has been minimized.

Copy link
Collaborator

commented Feb 24, 2019

@Ruediger34 Behind osmdroid's polyline, we use method Canvas.drawLines(float[] pts, int offset, int count, Paint);.
If just for a test you directly use Canvas.drawLines, do you still have those darker disks at each vertex?

@Ruediger34

This comment has been minimized.

Copy link
Author

commented Feb 24, 2019

Ok, I tested and got the following result:

grafik

This occurs always if the lines are overlapping. Very disappointing.

I suspect there's nothing we can do to solve this?

@monsieurtanuki

This comment has been minimized.

Copy link
Collaborator

commented Feb 24, 2019

If you find the good Paint set up, please share it with us.

Could you try with a Polygon instead of a Polyline, just to see the vertices?
Polygons use Path, Polylines use Canvas.drawLines.

@spyhunter99

This comment has been minimized.

Copy link
Collaborator

commented Feb 24, 2019

this issue is that each line segment is drawn individually. We used to have squared off ends which caused some funky rendering issues and switched to the rounded ends. When the line has a transparency, both line segments overlap a bit because the start point and end point are the same. To be more specific, the drawing of segment 0 ends at point x,y and segment 1 starts at x,y. Thus with a transparency it's drawn twice at that point.

If you use a solid line color with no transparency, this shouldn't occur. It might be possible to set the last point in a segment to no end cap or a 100% transparent version. Therefore the next segment would then paint it just once. It may work for relatively straight lines, but there will probably be overlap with closer to 90 degree bends.

@Ruediger34

This comment has been minimized.

Copy link
Author

commented Feb 24, 2019

@spyhunter99 yes, this only occurs with transparency.

Ok, probably the solution is to use canvas.drawPath instead of drawLine.
With canvas.drawLine:
grafik

With canvas.drawPath:
grafik

@spyhunter99

This comment has been minimized.

Copy link
Collaborator

commented Feb 24, 2019

i'm pretty sure there's a reason we use draw line instead of path. It was either performance related, or functioning correctly at zoom levels > 20. @monsieurtanuki probably remembers this as it was quite painful to get it performant and functional across all zoom levels

@monsieurtanuki

This comment has been minimized.

Copy link
Collaborator

commented Feb 24, 2019

@spyhunter99 Definitely performance issues like that!
That said, we might consider adding a boolean "usePathInsteadOfDrawlines" parameter in Polyline (default: false). I can't remember exactly what was wrong with Polyline vs Path, but if it's about zoom 22+ for instance, I guess users may prefer decent vertices (with Path) with still decent enough zoom levels (21 and lower).

@monsieurtanuki

This comment has been minimized.

Copy link
Collaborator

commented Feb 25, 2019

Why we use Canvas.drawLines instead of Path for Polyline: #834, #838.
@Ruediger34 Are you OK with potentially slower performances? Are you using large sets of data for your Polylines, or big zoom levels (like 20+)?

@Ruediger34

This comment has been minimized.

Copy link
Author

commented Feb 26, 2019

Interesting.
@monsieurtanuki Probably it's ok to have a performance impact but I can't estimate it in a real scenario.
My polylines have up to 400 geopoints (roundabout 20km) and I am using up to zoom level 19.

@monsieurtanuki monsieurtanuki self-assigned this Feb 26, 2019
@monsieurtanuki

This comment has been minimized.

Copy link
Collaborator

commented Feb 26, 2019

@Ruediger34 OK, working on it. I just cannot guarantee it will be satisfactory.

monsieurtanuki added a commit that referenced this issue Mar 2, 2019
New classes:
* `PolyOverlayWithIW`: extending `OverlayWithIW`, extended by both `Polyline` and `Polygon` given the number of common methods
* `SampleDrawPolylineAsPath`: sample similar to `SampleDrawPolyline`, but where `Polyline`s are drawing in the "path" mode (and not in the "lines" mode)

Impacted classes:
* `CustomPaintingSurface`: created mode `PolylineAsPath`; put alpha in the color in order to see the vertices for `Polyline`s
* `LinearRing`: added the `boolean` member `mClosed` in order to make both `Polyline` and `Polygon` draw using a `Path`; new constructor for `Path` with a `boolean pClosed` parameter; taking into account the `mClosed` member when building the `Path`
* `SampleFactory`: added `SampleDrawPolylineAsPath` just after `SampleDrawPolyline`
* `Polygon`: now extends new class `PolyOverlayWithIW`
* `Polyline`: now extends new class `PolyOverlayWithIW`

Impacted classes - slightly unrelated refactoring regarding `Paint`s:
* `Bug382Crash`
* `HeatMap`
* `LatLonGridlineOverlay`
* `LatLonGridlineOverlay2`
* `MarkerDrag`
* `MilStdMultipointOverlay`
* `OsmMapShapeConverter`
* `SampleMilestonesNonRepetitive`
* `SampleOsmPath`
* `SampleRace`
* `SampleZoomToBounding`
@monsieurtanuki

This comment has been minimized.

Copy link
Collaborator

commented Mar 2, 2019

@Ruediger34 I've just PR'ed #1285.
You can already see the difference in the new "More Samples / Drawing / Draw a polyline on screen as Path" demo.
Please have a go in your own app too.

monsieurtanuki added a commit that referenced this issue Sep 3, 2019
spyhunter99 added a commit that referenced this issue Sep 26, 2019
New classes:
* `PolyOverlayWithIW`: extending `OverlayWithIW`, extended by both `Polyline` and `Polygon` given the number of common methods
* `SampleDrawPolylineAsPath`: sample similar to `SampleDrawPolyline`, but where `Polyline`s are drawing in the "path" mode (and not in the "lines" mode)

Impacted classes:
* `CustomPaintingSurface`: created mode `PolylineAsPath`; put alpha in the color in order to see the vertices for `Polyline`s
* `LinearRing`: added the `boolean` member `mClosed` in order to make both `Polyline` and `Polygon` draw using a `Path`; new constructor for `Path` with a `boolean pClosed` parameter; taking into account the `mClosed` member when building the `Path`
* `SampleFactory`: added `SampleDrawPolylineAsPath` just after `SampleDrawPolyline`
* `Polygon`: now extends new class `PolyOverlayWithIW`
* `Polyline`: now extends new class `PolyOverlayWithIW`

Impacted classes - slightly unrelated refactoring regarding `Paint`s:
* `Bug382Crash`
* `HeatMap`
* `LatLonGridlineOverlay`
* `LatLonGridlineOverlay2`
* `MarkerDrag`
* `MilStdMultipointOverlay`
* `OsmMapShapeConverter`
* `SampleMilestonesNonRepetitive`
* `SampleOsmPath`
* `SampleRace`
* `SampleZoomToBounding`
@spyhunter99 spyhunter99 added this to the v6.1.1 milestone Sep 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.