Black ramps on mobile ES renderers

[nvkelso]

On my Samsung Galaxy S6 edge I see a lot of black ramps (links) both by highways and at other road intersections. Usually this is a mid-zoom problem, and zooming in the ramps assume the intended color. But true highway ramp to highway links don't seem as affected by this problem.

• Highway to non-highway: US 1 and Brotherhood Way in SF
• Non-highway to non-highway: Portola and Clipper by Twin Peaks in SF

[nvkelso]

[nvkelso]

I've heard similar reports from NYC about this.

[nvkelso]

Still showing as an issue in master-518 build :(

[bcamper]

I've not been able to verify this fix on device yet, but I believe that this may be the culprit, a malformed YAML reference:

-                    color: [[8, *major_road4], [13, major_road2], [17, *major_road1]]
+                    color: [[8, *major_road4], [13, *major_road2], [17, *major_road1]]

https://github.com/tangrams/eraser-map/commit/fbbbeb0cc62202da5a51da4c65d65f4b2a6e4a62

My theory is this:

• The reference read major_road2 instead of the proper *major_road2. Since major_road2 is not a CSS color, it fails to parse.
• On JS, a default color of white is used. (White is the default partially because of the rule that we don't require color for styles with a color or filter shader block -- in those cases we want a default vertex color of white so that any shader-derived color is preserved.)
• On ES, it appears that default color in this case is black (I don't know if that is intentional or not).
• My theory is that the white is close enough to the intended design that the effect is not noticeable in JS, while it sticks out like a sore thumb on ES. You can see in the screens above that the black starts lightening at higher zooms as it interpolates to the next correct color stop.

cc @blair1618 for thoughts on this theory (also someone should verify, I can't get my ES build to work at home currently :), and ideas on what default behavior should be across platforms.

[tallytalwar]

@bcamper Yup, this is it.

• This without the fix:
• This with the fix:

[bcamper]

I am on a debugging roll :D

On Thu, Dec 10, 2015 at 4:29 PM, Varun notifications@github.com wrote:

@bcamper https://github.com/bcamper Yup, this is it.

-

This without the fix: [image: screenshot from 2015-12-10 16-27-44] https://cloud.githubusercontent.com/assets/360641/11729029/2ef3afc4-9f5b-11e5-9f16-36abdb06ce5a.png

This with the fix: [image: screenshot from 2015-12-10 16-27-16] https://cloud.githubusercontent.com/assets/360641/11729023/1e473916-9f5b-11e5-95b5-564b2b6ad791.png

— Reply to this email directly or view it on GitHub https://github.com/tangrams/eraser-map/issues/97#issuecomment-163754888.

[matteblair]

Yeah that's exactly what was happening. The color is black because that's what css-color-parser-cpp returns when it can't match a string. We can pick a different color though. I would actually suggest some garish shade of pink or yellow because as you have just found, having a noticeable "failure" color makes it easier to spot unwanted behavior.

[tallytalwar]

In my previous work, I have usually used a cheddar cheese color as an error color or a default color. However thats my personal preference, because I tend to not like the color.

http://images.myperfectcolor.com/repositories/images/colors/MPC00052407-2.jpg

[nvkelso]

Brett fixed this (was missing a * in front of the YAML anchor ref).