Memory cache is caching missing tiles

[karlrado]

Describe the bug
I'm fairly sure that the memory cache is caching tiles/chunks that contain the default solid background color when a tile/chunk cannot be loaded before the maxwait timeout expires. This isn't a huge issue when someone has maxwait set to a reasonable value and isn't getting a lot of missing chunks. But even if only a few get into the cache, it isn't a good use of cache memory.

I do intend to look into this more myself at some point, but I am not super-familiar with the memory cache code. So if someone else can quickly confirm or fix, that would be great.

To Reproduce
Steps to reproduce the behavior:

1. Delete all AO cache files
2. Start AO and set the maxwait to the smallest possible value
3. If you have the missing color PR, use that to set the color to red or something that stands out. Otherwise, be prepared to look for the default gray color.
4. Start XP anywhere on the ground. Use the Free Camera (c) to look around and note that there are a lot of missing tiles, which is expected.
5. Quit XP, but leave AO running (IMPORTANT)
6. Start XP again in the same place and look around in the same way as step 4. Note that the same tiles are missing.
7. Stop XP
8. Stop AO
9. Start AO
10. Start XP and do the same thing as in steps 4 and 6. Note that there are far fewer or no missing tiles.

Expected behavior
There should be no missing tiles in step 6. Steps 6 and 10 should look the same.

(please complete the following information):

• OS: n/a
• XPlane Version: 12.2.1
• AutoOrtho Version 1.2.6 + PR Add control to change the missing tile color #75
• Filesystem type n/a

Additional context
Upon reaching step 6. AO should have downloaded nearly all the cache files needed for the scene. All the downloads were started and completed in step 4, but the low setting for maxwait prevented many of them from being used, resulting in a lot of tiles being filled with the missing color and cached in the memory cache as such. So a lot of the tiles are present in the FILE cache, but stored in the MEMORY cache with the solid missing color.

Leaving AO running in step 5 retains the MEMORY cache state, thus holding a lot of tiles filled with the missing color.

Restarting AO in steps 7 and 8 clears this MEMORY cache state and allows the correct tiles to be read from the FILE cache, resulting in fewer missing tiles in step 10.

If all of these observations and explanations are correct, the fix would be to simply not add a tile/chunk to the memory cache if it ended up getting filled with the missing color.

[ProgrammingDinosaur]

Hello

You are right, this can be a problem and it's an issue with the current caching logic. The thing is that the fix is not very straightforward

Let me explain

Currently the Tile opening logic goes as follows.

---

1. X-Plane requests via FUSE a DDS file
2. We parse de DDS file to get the Tile it belongs to (row, column and zoom in slippy tilenames fashion)
3. With that data the program checks if the Tile exists in cache or not, if it exists reuse that Tile data
4. If Tile is not cached we create it and start image downloading and DDS build,
5. When a Tile is built is added to the memory cache

The memory cache holds the images for the tiles so it can regenerate the DDS without downloading again. The cache will hold at minimum 25 Tiles for quick reuse. There is the problem you are having, when closing X-Plane and opening again the program uses the cached Tile data for faster rebuilding.

---

The main complication of approaching this issue is how the DDS building works and the Tile Cache, since the modification of an already opening tile for patching it up can be delicate.

While every 1 Tile = 1 DDS output every DDS is compromised of various Chunks (default is 256 chunks per tile for a 4096x4096 ZL16 image), which are 256x256 images that we get from the image providers. It's during this chunk retrieval where if we do not retrieve correctly a chunk in the maxWait timeframe it is replaced by the solid image and handled to the DDS builder.

In here once a DDS is built and the Tile has all of the chunks it needs it deletes the chunk data and keeps the fully built images (for the DDS mipmaps). So once the DDS is built there is currently no way to go and patch the missing chunks, since we don't know which are they and it would require to rebuild the full DDS.

The fact that AO does not have any "is X-Plane running?" logic makes the detection currently harder.

A fast solution could be that if X-Plane closes we flush the Tile Cache. It's a middle ground since the downloaded JPEG's of chunks will still be there for reuse but we force a new Tile generation for every X-Plane session, allowing the missing tiles to be patched up even within the same AO session.

[ProgrammingDinosaur]

I am currently working on an update that will overhaul many things of the DDS build and Cache system. I will consider this point for the implementation

[karlrado]

This is a great explanation. Maybe you can copy/paste it into a wiki or some other "how it works" document on this GitHub. But see my notes below the line.

Yes, I was hoping that this was just a simple oversight and could be corrected by flagging bad chunks and not caching any tile that uses a bad chunk. But I see now that it is more complicated. But I don't know, couldn't you go ahead and construct the "virtual DDS" tile in memory and simply not cache it if any of its chunks are bad? It seems that a "bad" flag maintained for each chunk could be added. The point is to avoid caching it (the DDS tile) in the first place, and not try to patch it later.

If it can be avoided in the rework, that would be great. But it probably isn't super important. My scenario is a little contrived. You sort of have to force it to happen. I also suspect that most users would tune their maxwait to get a good balance between bad tiles and stutters, resulting in not so many bad chunks in the cache. And the tile (memory) cache would eventually evict the bad tile if enough new tiles come in.

You can close this issue if you want. I'm glad we were able to discuss it.

---

Suggested improvement of the steps 1 and 2 explanation above:

As I understand it, the AO downloaded scenery has no DDS files in it. AO serves them up to XP "virtually".

So, in step 1 above, XP executes a simple OS-level file read command. This command contains the file name, starting offset into the file, and length of the data to return. The file is a DDS file that doesn't exist. FUSE (Dokan or WinFSP) intercepts this OS-level file system call and calls the "file read" callback in AO. The file read system call doesn't have any information in it that indicates tile row/column or zoom since the file read call has only offset and length. But AO can still figure it out.

In step 2, we know the structure of the DDS file, so we can use the offset to figure out the ZL and lat/log and use that to come up with the tile's row, column and zoom.

Perhaps this explanation is more accurate than saying "parsing the DDS file", which doesn't really exist. Step 2 could just say "computes the tile row, column, and zoom from the file read parameters" or something.