icon-text-fit-padding produces inconsistent pixel padding

[tristen]

I'm using two icons that are identical in dimensions. Here's an example of the first:

<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 40 18" height="18" width="40" version="1.1">
  <path d="M 40,0 0,0 0,18 40,18 Z" fill="#70A5E7" />
</svg>

On duplicate layers to create an outline effect by setting the icon-text-fit-padding values to be 1 pixel larger than the second . But the pixels appear inconsistent in cases

---

mapbox-gl-js version: v1.1.0
browser: Google Chrome Version 74.0.3729.169 (Official Build) (64-bit)

Expected behavior

I would expect the value of icon-text-fit-padding in the first layer to be evenly padded by 1 additional pixels

Link to Demonstration

https://jsfiddle.net/s1fxmvn2/embedded/result/?username=tristen

[ansis]

Some speculation: this is caused by linear interpolation. Since we're stretching the icons we can't snap them to a pixel grid. Since we can't snap them to the pixel grid the 1px boundary isn't necessarily one crisp pixel. I'm not sure this can be quickly fixed.

But that is just speculation and someone needs to actually dig in.

[kkaefer]

@ansis I think the opposite is the case: The JSFiddle above uses nearest-neighbor texture scaling. As soon as you rotate the map, it switches to linear interpolation, and—at the expense of being less crisp—all borders show up.

[chloekraw]

Quick note, for a customer implementation we're suggesting that they use 'icon-text-fit-padding': [1, 3, 3, 3] to get a consistent padding across all four sides. There's only one icon used (unlike the jsfiddle). The customer would like an explanation of why this occurs. It's likely okay if we can't fix it.

[kkaefer]

This gets slightly better with #8741, as well as #8730, but won't be entirely resolved. The underlying issue is that we image is still stretched, which means that the frame "border"'s pixels will get stretched into the neighboring pixel. Without #8730, they could be in a pixel that nearest neighbor texture lookups omit entirely. With that change, it means that they border will be somewhat blurry or fainter because it is rendered or stretched across a pixel boundary. To fix this correctly, we need #4143.