search

tangrams / tangram

WebGL map rendering engine for creative cartography
https://tangram.city
MIT License
2.22k stars 290 forks source link

proxy tiles don't depend on scroll direction #762

Closed bdon closed 4 years ago

bdon commented 4 years ago

The visibility of over/underzoomed "proxy tiles" when the current view tiles aren't done loading was determined by the instantaneous view state: +1 when zooming in, -1 when zooming out. This assumed that ZOOM-1 tiles are loaded when zooming in, and ZOOM+1 tiles are loaded when zooming out. This assumption works fine when slowly paging through zooms in one direction, letting each layer load at a time, but breaks down if the direction of the scroll is reversed within a zoom level that isn't done loading.

Comparison video of before/after, that flies 4 zoom levels in in 300ms, and 2 levels out in another 300ms:

Video Link (mp4)

This doesn't solve all visibility issues related to flickering tiles I've noticed - may demand a larger rethinking of how TilePyramid and tile visibility/proxy tile states work

bcamper commented 4 years ago

This looks like a nice improvement! @tallytalwar says this is more like Tangram ES behavior. I honestly can't remember what the reasons were for tying this to zoom direction were, too long ago 😭, but I believe it pre-dates the current tile pyramid implementation and so may just be vestigial.

The only thing I would like to check a bit more before merging is to ensure that tiles are always properly released once things "settle". Looks like it ought to from your change, but just to feel comfortable we don't end up with a leak.

I am definitely interested in any further feedback / isolation of cases where you've seen other flicker or unexpected tile behavior. The only other relevant behavior off the top of my head is that there is a limit to how many zoom levels in/out proxy tiles will be displayed at. This is a subjective / aesthetic choice though -- mostly because I was observing cases where a tile from 4-5 zooms out was displayed and both the geometry detail and styling were so far off the "correct" representation once the local tiles loaded that it seemed to be causing more harm/distraction than good. That can also be revisited though.

bcamper commented 4 years ago

Love this. I tried messing around with preferring descendant tiles instead of ancestor tiles... but feels like that and related changes need more thought, so no need to block this.

In terms of "flickering": if I recall, it is going to release any tile that doesn't meet at least one of the following conditions:

  1. In the view bounds for the current zoom
  2. Acting as a proxy tile for a visible tile that's currently loading
  3. Within at least one zoom level of the current zoom (preserve_tiles_within_zoom)

So given that, flickering could occur for tiles that were loaded and then released because they are more than one zoom level away. Another approach could be to hold onto any tile that could be a proxy for any tiles that are loading (so all ancestors and descendants), and then only release them when the tile is finished loading. This would cover cases where the user switches direction and/or traverses multiple zoom levels. The only concern would be if it caused too much memory usage to build up during some zoom transitions; probably would be OK, but should at least be benchmarked.