Flickering on zooming out with controller.setZoomEased

[westnordost]

While zooming out via controller.setZoomEased on Android 5.1 with tangram-es 0.9.6 but possibly since always, the map shows nothing for a few frames at certain zoom levels. When zooming in and out a lot via this method (*cough* StreetComplete), this can become quite disruptive.

A video shows more than thousand words: https://www.westnordost.de/misc/zoom-in-zoom-out.mp4
If you skip through here frame-by-frame, you will notice that at certain frames, the map is suddenly empty and in the next frame, everything is as normal again.

I cannot reproduce the issue when I zoom in and out manually (using the zoom gesture with my fingers), even if I do this very fast.

[matteblair]

🤔
I suspect that the tile flickering and the single-frame-zoom-jump are different issues, but both are weird and I'll try to reproduce them.

[tallytalwar]

We might have already addressed these with the newer camera animation interface work in 0.9.7-SNAPSHOT.

[westnordost]

How can I try out 0.9.7-SNAPSHOT?

[matteblair]

To try out the snapshot versions first add the jfrog snapshot repo to your Gradle dependency config:

dependencies {
  repositories {
    maven {
      url "https://oss.jfrog.org/libs-snapshot/"
    }
  }
}

And then use the snapshot version in your module dependencies:

dependencies {
  implementation 'com.mapzen.tangram:tangram:0.9.7-SNAPSHOT'
}

Be warned however that this snapshot represents a fairly big version change and there are some major API changes between this version and the last published version.

[westnordost]

Ah, well, it cannot be that much, I will try out the new version and report back.

[tallytalwar]

Thanks, while you are at it, will also welcome some feedback :D.

[matteblair]

Hey thanks for the feedback! Some of those bullet points have good answers and others might be reasons to change things:

• It probably isn't a good idea to create new objects every frame - I expected camera updates to be relatively infrequent! We can probably make things better for frequent updates, but if your compass is making changes at 60Hz then maybe tell it to chill out :)
• We made a factory for camera updates because in general updates are not compose-able. Some updates make sense to combine, but if you combine a newLatLngBounds update with a zoomBy update then the result depends on the order they are applied. For the most general case you can just create an arbitrary camera position (though yeah - it's more verbose than before).
• Camera update and position are probably a little confusing: a camera update effectively transforms one camera position to a new camera position
• Android animation frameworks aren't really suitable for our renderer because they animate on the UI thread and we render on a separate GL thread
• If you want to just change the current rotation, it's an easy one-liner:

controller.updateCameraPosition(CameraUpdateFactory.setRotation(radians));

[westnordost]

Anyway, </feedback>, back to the topic:

I tried it out and the flickering as described in this ticket definitely exists in 0.9.7-SNAPSHOT as well.

Regarding the first frame being already at the zoom target (mentioned in first reply), this seems to be gone in 0.9.7-SNAPSHOT.

[matteblair]

🙏 Thank you for all the feedback and testing! Seriously, it's high-quality feedback.

That flickering is probably a bug in the proxy tile logic - the tiles at the lower zoom level are clearly loaded already, so there should be no visible gap in coverage.

[westnordost]

I haven't been able to reproduce #1772 so far on my smartphone with debuggable libtangram.so, but I noticed that the flickering-problem is much worse then. So, the slower the device, the more apparent this issue.
This hints to that perhaps there is no real bug as such but the way zooming is implemented isn't able to keep up when the zoom level changes very fast.
What happens when the thread doing rendering and/or loading the tiles can't keep up? Are the render results per tile and zoom cached as bitmaps?

[westnordost]

Sadly, still same behavior in 0.11.2.

However I further analyzed this behavior and found out what triggers it. I opened a new ticket with better information here: #2131