Imagery From Files Fail To Render on ATAK about androidtacticalassaultkit-civ

[takdeveloper]

@kenktk Thanks for reporting the issue. We'll pull some imagery from the referenced site and test with versions starting with 4.3.1.5. Thanks for including the version information!

[kenktk]

So I have been working on this problem. The imagery sometimes loads but it takes a very very long time in order for it to finally render. It used to not do this before some patch. I wonder if this was a change at how imagery was rendered as to not throttle other UI components from high system usage.

[kenktk]

Further observations on this imagery rendering, compared to downloading tiles via the WMS server, is that imagery loaded from the filesystem has larger tile sizes compared to when ATAK downloads the tiles from the WMS server. This makes the rendering of WMS downloaded tiles easier for the system to handle.

[takdeveloper]

@kenktk There should be noticeable improvement with this issue coming with ATAK 4.7. Performance should be more in line with ATAK 4.2 and prior.

There were a confluence of issues that contributed to the slowdown:

• 4.3 reimplemented the globe to pre-render the terrain surface (e.g. imagery) into separate textures, one per terrain tile.
  • Terrain tiles are defined on a uniform grid, and not clipped to the viewport. This results in more imagery tiles to be requested to fully form the scene.
  • ATAK does some prefetching of lower resolution terrain tiles that are offscreen to show data more quickly during pan/zoom. Terrain surface rendering for a given terrain tile evaluates at the resolution of that tile. For non-pyramided imagery this means subsampling. Subsampled imagery reads are more expensive than non-subsampled reads. The image reading worker can get bottlenecked if there are highly subsampled reads queued up.
  • Terrain tile population triggered imagery loading, meaning that imagery tiles would be queued in the order that terrain tiles were populated (arbitrary). This caused a general degradation in prioritization for data loadouts using imagery chips as opposed to tile pyramids.

As you noted, the texture size is also different between tile pyramids (256x256) and non-pyramid data (512x512). I know we explored switching to a 256x256 size -- but I can't recall whether or not it had an impact on throughput.

I will close this issue once the 4.7 release is pushed.