Add 'tiles-settled' event for robust detection of visual stability

[tobias74]

Description It seems that tiles-load-end fires as soon as the download queue is empty, which can happen before the scene is fully stable (e.g. before children are queued).

I introduced a tiles-settled event that waits for 2 consecutive frames of inactivity to ensure the renderer is truly done.

Use Case I am using this in a headless worker for elevation raycasting. The standard tiles-load-end event was occasionally causing me to sample low-resolution tiles; this new event solved the issue.

[gkjohnson]

Thanks! I think it would be best to fix up the tiles-load-end event, though, so we don't have these blips of "download complete" before starting again when there's no camera movement. Just waiting for a couple frames doesn't seem so robust. Do we know why this seems to be happening? Notionally it should be the case that there's always something "in progress" until the tiles are all loaded.

1. Tiles are added to the download queue, including internal tileset json files (downloadQueue)
2. Content downloads and tile is immediately moved to the parse queue (parseQueue)
3. Tile is parsed and removed from the parse queue.
4. Next call to "update" the children are added to the "processQueue" (processNodeQueue)
5. Children are process and removed from the queue
6. Next call to "update" the children are traversed and new tiles are added to the download queue if needed (go back to step 1)

[tobias74]

I need to make a couple of more checks.

I am not completely sure, but I think the issue is that the function markVisibleTiles calls renderer.queueTileForDownload( tile );

which in turn might not queue all tiles in case the lruCache is full.

So in this case in one of the upcoming calls to update() there might be new tiles on queuedTiles even if in the previous call to update() all the queues seemed to be empty?

I will investigate further :-)

PS: The premature "tiles-load-end"-events almost never occur during "normal" use of the renderer. They only happen when I "hammer" the renderer with high frequent changes to the (lat/lon) the camera looks at.

[gkjohnson]

I'm not able to see any stuttering of load end events after the camera stops moving when scrolling around the Google Earth data example even when lowering the lru cache size. A simple repro would be helpful - until this is understood, though, I don't think solutions like waiting X frames are generally reliable and shouldn't be included in the project. But it is something you can implement yourself using the existing events.

They only happen when I "hammer" the renderer with high frequent changes to the (lat/lon) the camera looks at.

If you're changing the camera view then it should be expected that new loads have to start and will fire new "end" events. Are you saying you expect something different to happen here?

[tobias74]

I have to start from scratch, I have now run extensive tests, and the 2 frame wait indeed does not reliably solve my problem. I will close my PR for now, since it does not deliver a reliable solution