Area fill colors get corrupted upon scroll (Android).

[mb12]

This is consistently reproducible on Samsung Nexus S.
Just go to any area with fill colors and scroll. I've attached two screenshots from Samsung Nexus S (one that shows expected fill colors and the other that shows corrupted fill colors).

[mb12]

Here is another screenshot illustrating corruption.

[ljbade]

Hmm this is interesting.

Have you seen this before on iOS (or Android) @kkaefer @1ec5 ? I haven't

[ljbade]

@mb12 Does this only happen on Nexus S? Have you been able to reproduce this on other phones?

[1ec5]

I haven't seen this issue on iOS. The closest thing I can think of is that fills are all screwed up after loading Pencil style.

[kkaefer]

Never seen this issue on my Moto G 2 test device.

[mb12]

@ljbade Consistently reproducible on Nexus S. Does not happen on Note 3.
@1ec5 What is the pencil style issue you are referring to? Is it consistently reproducible?

[mb12]

The "Light" style shows red lines and smudges even without scrolling. (Consistently happens on Nexus S. Does not happen on Note 3).

[1ec5]

What is the pencil style issue you are referring to? Is it consistently reproducible?

See #636 and https://github.com/mapbox/mapbox-gl-styles/blob/mb-pages/styles/pencil-v7.json.

[mb12]

Sometimes lines disappear on scrolling as well. I've attached two screenshots (one with lines and one without lines).

[ljbade]

@mb12 Can you get the GL info from your phone? It will be in the app logcat towards the start.

This is either an interaction with some specific set of GL extensions your phone has, or some sort of bug in the GPU driver for your phone.

[mb12]

Is this what you are looking for?

https://gist.github.com/mb12/cf952c89c26137dcc3a4

[ljbade]

@mb12 thanks

[erf]

I have a similar problem on a Samsung S3 (Android version 4.4.4). Some tiles don't always load it seems or rendering is invalid.

[mb12]

@ljbade and @bleege Is it possible to analyze this for B1? There are at least two devices where this reproduces consistently (S3 and Nexus S).

I would be more than happy to mail you one of my test devices to reproduce the issue.
I also checked that Nexus S is available for $30 or so on ebay (Buy now price).

[bleege]

@mb12 Could you provide some more information on the S3? Specifically, Android API number that your device is running. It's an older phone that looks like it originally came with Android 2.3.

[mb12]

It's 4.1.2

[mb12]

@ljbade The symptoms of this bug look very similar to z fighting. Is it possible to have this code reviewed (esp. the usage of glDepthRange, glDepthMask in translucent phase etc)? z fighting may also explain why symbols/lines sometimes disappear upon panning or just do not show up on some Android devices. I've verified that the Depth buffer size is 24 bits on the device where it reproduces (Its also 24 bits on where it does not reproduce).

https://en.wikipedia.org/wiki/Z-fighting

[mb12]

@kkaefer , @ansis , @jfirebaugh Is it possible to prioritize this bug since it happens on a variety of Android devices (Similar symptoms have also been reported on S3, Lenovo Tab, Nexus 10 running Android 5.1). It looks like a combination of several bugs in the opengl client code. I've included some of the analysis below.

1. There is definitely a bug in antialiasing code for fill buckets. Just commenting out the relevant code in Painter::renderFill gets rid of the reddish fringe line around fills.
2. Usage of strata_epsilon can also cause issues. The strata_epsilon value is 2^-16. This will definitely have an issue with some android devices since we request EGL configurations with depth buffer >= 16 bits. There is no need to use strata_epsilon. It can be logically changed to use strataThickness/2 etc to improve precision issues.
3. Depth precision can also be improved by adding a zlevel to RenderItem and incrementing it on a per layer basis instead of per tile basis.

[kkaefer]

@mb12: thanks for your observations, certainly looks like these are multiple bugs. Can you check whether https://github.com/mapbox/mapbox-gl-native/tree/fix-android-rendering-bugs fixes any of the above bugs for you?

[mb12]

This still reproduces the issue.

1.) For lines, very frequently the map goes to a state, where panning to one side causes the line to disappear and panning to the other makes them appear (similar to this issue #1478). This happens on master repo as well. I've attached two screenshots showing the line disappearance issue.

2.) Red lines around fills still persists and they expand to fill the area upon pan.

[mb12]

Here is more information regarding the lines disappearing issue:

1.) Lines disappear/appear at a point a new tile enters/leaves the Viewport. By this I mean, with renderDebugFrame turned on, move the red frame line into and out of the ViewPort.

2.) Whenever this happens, the list of RenderItems changes, resulting in new depth ranges being mapped to each RenderItem bucket.

3.) The issue happens independently of fill buckets. Remove fill style layers from style.json or always return nullptr from TileWorker::createFillBucket.

[mb12]

@kkaefer I have been able to narrow down the line disappearance issue to LineSdfShader. If I replace dashed lines with regular lines in the style or make the equivalent change in painter_line.cpp the disappearing line issue goes away. I am unable to figure out how panning can interact with LineSdfShader causing lines to disappear. Please do let me know what else I can try to narrow down the issue further.

[erf]

Map is really messed up now in commit d400fe0 on a samsung s3 device

[ljbade]

@erf Are you still seeing this issue?

[adam-mapbox]

FYI I have a Galaxy S3, running 4.4.2, and I can't reproduce any of these issues with the latest master. Not sure if we fixed it, or if it's the Android version, or what.

[adam-mapbox]

It's been a while since we've heard much noise about this particular issue, and we haven't been able to reproduce it in-house. Can we get a status check on this @mb12 @erf and see if things are still wonky? A lot has changed in the meantime and it's possible that either we fixed this inadvertently or that it only shows up on very old Android versions.

[mb12]

@adam-mapbox It consistently reproduces on Galaxy Nexus S. @ljbade also purchased one from ebay and confirmed that he was able to reproduce the issue. This issue no longer reproduces on S3.

[bleege]

@mb12 Can you confirm what version of Android (API level would be ideal) that the Galaxy Nexus S is running? According to Wikipedia it's running 2.3.3.

[tobrun]

I haven't seen this issue on other devices, including the screenshots taken from 220 devices on AWS device farm and the Nexus S is a device from 2010 and is too old to keep supporting. Closing.

[mb12]

@tobrun Do you know if there is a way to mark a particular device as unsupported in AndroidManifest.xml?

[tobrun]

Not in the AndroidManifest.xml but you can do this in Google Play Developer Console:
Here is for example a screenshot where you can disable the mentioned device: