We have another project that uses Cesium and it takes our (slow) system ~20 seconds to display our first polygon or polyline. Subsequent polys will display immediately. Is there anything we’re doing wrong? Can we do anything to avoid the lag in displaying the first poly?
I am attaching a basic sandcastle where you can see the problem if you run with an empty browser cache (cached images & files).
Any tips are appreciated. Thanks!
We are Windows 10, Chrome 80, i7 7820, NVIDIAQuadro P3000, 16GB RAM.
This is happening because there’s an initial overhead of loading the web workers used to compute the geometry asynchronously.
You could potentially work around this by using the Primitive API which allows you to create geometry synchronously, at the cost of some camera jitters while geometry is loading.
Is there any way to have the web workers load early like upon initialization of Cesium?
We were using Entity API because we needed to do lots of updates to our data and didn’t want to deal with always deleting/recreating things using the Primitives.
Is there any way to have the web workers load early like upon initialization of Cesium?
Did you discover a way to load the web workers Omar mentioned when Cesium is initialized?
We’re having the same problem. The first time a polyline is drawn there is often a very significant delay (10 or more seconds) before the line becomes visible. Subsequent lines are drawn instantaneously.
I never found a good way around it. Switching to use Cesium Primitives instead of the Entity API is one solution. Other than that, we still have widgets that take 20-30sec to draw the first polygon.
Jumping on this thread as well. I’ve been exploring this issue in the Sandcastle and seeing that the first render after adding entities is slow and causes a freeze (easily visible if camera is moving).
It would be nice if we were able to pre-load web workers on Viewer init.
Thanks for pointing out that web workers have been inlined.
That makes it stranger that I’m still seeing an extended stutter/freeze in my Sandcastle, which is running on v1.116.
I went looking for the cause in Chrome’s Memory profile list and found that only 2 “JavaScript VM instances” populate the list by default, but once I draw some entities (and cause a slight freeze), an additional 6 options populate the list.
I’m not certain what this indicates, but to me it means Cesium is allocating more resources as needed (I assumed web workers) and this is likely the cause of or related to the freeze I’m seeing.
Note that removing the entities and drawing again is much better; it still stutters, but much less.