ComputeLoadProgress() Inaccuracies

Hi all,

I’ve been working on some progress bar functionality for loading/updating some WMS tilesets, and noticed that the ComputeLoadProgress() function often returns 100 before the tiles have fully loaded. Please find some screenshots attached below:

When it returns 100

When it is actually fully loaded (several seconds later)

Am I misunderstanding this behavior? Is there potentially a workaround for this issue? Any and all advice would be greatly appreciated. Thanks!

Hi @alec_zhang1,
That sounds like a bug. Can you help us reproduce it? Does it always happen, or only with particular tilesets or when interacting in particular ways?

In my experience with Google tiles, I’ve had to add a delay of ~400ms before accepting the return value of ComputeLoadProgress() as valid. I had assumed that it takes a moment for Cesium to load enough metadata to know what it doesn’t have.

1 Like

Did some more testing today and this issue seems to be tied to the WMS Raster Overlay – I’ve been using ComputeLoadProgress() with other global tilesets and it seems to work fine there.

A little more about my set-up: I’m currently pulling this WMS data from a proxy server which passes along the requests (doing this for auth purposes).

The LoadProgress value consistently reaches 100 a couple of seconds ahead of the tileset (seems to depend on network speed or some other latency) when pulling from this server.

I am also updating the WMS overlay URL and layers occasionally, so not sure if that might also be related to this issue.

Hi folks, do you mind giving yesterday’s v1.16.0 release a try to see if you still have this problem? We reworked the progress computation a bit in this release, which may (:crossed_fingers:) have fixed it for you.

Hey Kevin,

Thanks for the heads up!

Just updated to v1.16.0 and gave it a try, but unfortunately I’m still seeing similar things with the WMS layers :confused:
not sure if there’s something else going on in the back…