moagrius/TileView

Tiles not properly laid out when Scale < 1 with remote tiles

LRP-sgravel opened this issue · 15 comments

LRP-sgravel commented

I'm trying to use your TileView to display a tiled large document. I'm having a problem when the Scale goes under the value of 1. Tiles are not properly laid out, the engine tries to display extra columns (black tiles on the right) and I also get a lot of bitmap decoding errors when going back to a scale of 1 or larger until it all settles down by panning.

Scale = 1
image

Scale = ~0.37
image

LRP-sgravel commented

I'm getting a similar result in the Http demo. Tiles do not align (and load extremely slowly)

image

moagrius commented

Can you post your project somewhere I can view it?

LRP-sgravel commented

Unfortunately, no. First, it is a Xamarin project with bindings I created. Second, it's an extremely large customer's project that includes iOS, WPF and a web back and front end...

moagrius commented

Have you tried previous stable, 2.7 something?

LRP-sgravel commented

Not yet, let me try to add a demo activity that uses our tiles URL and see how it behaves.

LRP-sgravel commented

Alright, so I'm getting the same result in teh demo using this activity :


import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.os.Bundle;
import android.support.annotation.Nullable;

import com.moagrius.tileview.Tile;
import com.moagrius.tileview.TileView;
import com.moagrius.tileview.io.StreamProviderHttp;
import com.moagrius.tileview.plugins.LowFidelityBackgroundPlugin;

public class TileViewDemoSmartUse extends TileViewDemoActivity implements TileView.TileDecodeErrorListener {

  private TileView mTileView;

  @Override
  protected void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_demos_tileview);
    frameToCenterOnReady();
    mTileView = findViewById(R.id.tileview);
    mTileView.setTileDecodeErrorListener(this);
    mTileView.setMinimumScale(0.25f);
    mTileView.setMaximumScale(2.5f);
    new TileView.Builder(mTileView)
        .setSize(3456, 2592)
        .setStreamProvider(new StreamProviderHttp())
        .setDiskCachePolicy(TileView.DiskCachePolicy.CACHE_ALL)
        .defineZoomLevel("https://smartusev5canadaeast.blob.core.windows.net/content-a6c5a7a4-902f-4f73-bf9a-b53044f6e5e1/3d2481d0-1b84-43d7-865e-1d732770c4cd/200/tile_001_%1$03d_%2$03d.png?sv=2017-07-29&sr=c&sig=BUOF9sn%%2BeCQNLlRkg%%2FghdntzwMvP3hjQ1CrMBccT%%2FZ8%%3D&se=2019-06-08T15:06:01Z&sp=r")
        .build();
  }

  @Override
  public void onTileDecodeError(Tile tile, Exception e) {
    mTileView.retryTileDecode(tile);
  }

}
moagrius commented

I'll give it a shot tonight or tomorrow

moagrius commented

I ran it briefly when a I had a down minute at work. Since you're URLs are HTTPS (rather than HTTP), you probably want tochange line 16 of StreamProviderHttps to HttpURLConnection connection = (HttpURLConnection) url.openConnection();

That gave me decent results, but with the latency of a network with our aggressive caching, network is a weak spot right now.

I'd suggest either:

  1. User the stable version 2 build. it's here as https://github.com/moagrius/TileView/tree/version-2.7.7 (which is actually a typo, it should be 2.2.7), as implement com.qozix:tileview:2.2.7, or i think you can grab it all the way up to patch 9 with the old namespace: implement com.qozix:tileview:2.2.9. The API is slightly different but that lived in the wild for several years and is pretty mature. This version is not as optimized for a single tile tile - if you have multiple scales (say 0.5, and 0.25) you should probably create those sets and pass them to the TileView.

or...

  1. if you're always using the same set of tiles, i'd download them all upfront and keep them on disk, and use internal or external stream providers, or even a custom one from the cache dir if you don't want them to persist between installs. It won't actually use any more space since you're using disk cache anyway. This will give you much faster and more reliable local read and decode.

I do plan on returning to the remote images bug (I believe there's still an open issue), but it's probably going to be a month before I can put serious time into this project again.

LMK what you decide, and good luck.

LRP-sgravel commented

Version 2.2.9 is even worse. I can't even get the document to properly layout at any zoom level. The tiles flash all over the place, panning and zooming swaps the tiles around. This library simply doesn't appear to work for our very simple scenario. Not sure how this is possible given the history of your library.

LRP-sgravel commented

image

Then I pan and look at the top, new tiles have loaded...

image

moagrius commented
LRP-sgravel commented

I could try, I just don't see how it's related. Your engine doesn't know if the input stream / bitmap comes from the web or not and it lays out images seemingly randomly. Changing the location of the data doesn'T appear to have anything to do with the issue.

moagrius commented
LRP-sgravel commented

No worries, I know what lacking the time to do all those great projects feels like. The link I provided will have expired by the time you get to looking into it as it is session bound. Hopefully you ca reproduce some other way.

I'm not comfortable using a library with what definitely looks like a race condition into a production software.

moagrius commented

Totally understandable, and good luck with your project!

Just for documentary purposes, and future readers, this bug only applies to remote tiles (tile image files on a web server, fetched over http or something similar).

And a final note to self: this could also be a disk caching issue.