1. A concise explanation of the problem you’re experiencing.
Large numbers of (time-independent) label entities (~10000) leads to serious performance degradation.
Wondering if the core code changes presented in Cesium Blog - Entity API Performance are still the suggested path, or if there’s other ways to improve performance.
It seems like the core issue here is we don’t need to perform updates on each tick for entities that aren’t time dependent.
2. A minimal code example. If you’ve found a bug, this helps us reproduce and repair it.
3. Context. Why do you need to do this? We might know a better way to accomplish your goal.
In my application i’m loading a ~10000 item Lunar nomenclature GeoJSON. We like to show these labels while presenting the user with an animation of the Lunar satellite orbiting the globe. I have the labels set with various distanceDisplayConditions so the user is only seeing labels for features as they get closer to them. With the sheer number of features I don’t expect performance to be great but in the past it was at least usable. Either changes in Cesium (maybe SDF label rendering?) or changes in my application have made showing labels for nomenclature unusable for our users. In doing basic profiling in Chrome tools the LabelVisualizer.update() method seems to be where most of the time is being spent, so looking to minimize this if possible.
4. The Cesium version you’re using, your operating system and browser.
Latest Cesium
The above code example link:
Ubuntu 18.04
Chrome 78.0.3904.87 (Official Build) (64-bit) - slow but usable
Firefox 72.0.2 (64-bit ) - virtually unusable; tile/terrain loading significantly impacted; very jittery/laggy camera movements
iOS 13.3.1
iOS Safari - causes crash and reload after which point it seems to work with good performance;
Editing my app bundling to match the cesium-webpack-example and bumping to 1.66 seems to have greatly helped performance. I had followed the guide before, but had not updated it since the ES6 transition.
The behavior for the cesium sandcastle link above still remains. My app and the sandcastle example still crashes on iphone when loading lots of features (which did not happen for cesium<=1.62), but on other platforms is better behaved.
Thanks for posting all your debugging details here!
If version 1.64 is indeed where the performance hit first occurs, and gets fixed in 1.66, then it’s likely the useBrowserRecommendedResolution change here:
This is even more likely if you’re mainly seeing the issue on mobile devices, where the browser will typically request a lower rendering resolution and scale it up, in cases when the device’s GPU isn’t powerful enough.
For the crash you’re still seeing on iPhone, does distanceDisplayCondition not help? It could be that the labels are hidden in the shader, so it still requires a draw call. In which case, setting some labels explicitly to show: false might work (and in that scenario, you might need to create some kind of spatial grid, so that when the camera is close enough to a specific point, it sets all labels within a specific area, to show:true this array would be computed ahead of time).
Can you share the webglreport (http://webglreport.com/) for the iOS device you’re seeing the crash on?
I also wanted to say this sounds like a super cool project! Is this going to be publicly accessible?
Yeah I think you’re right in that useBrowserRecommendedResolution change is what did it.
distanceDisplayCondition certainly helps and i’ve had it in place for rendering nomenclature. Maybe I could play around with making it a little stricter.
I’ll look into the spatial grid show setting approach you suggest, but it is a bit of a bummer since optimizations like this weren’t needed before. Are there any example implementations of this spatial grid approach out in the wild I could take a look at?
And thanks, yes, the project has been a blast to work on and I think turning out pretty cool!
It is public at https://quickmap.lroc.asu.edu/ (built with react+ol+cesium, to get to Cesium click Globe option in projection menu)
The use-case I’ve been trying to optimize for is this view http://bit.ly/2vsvet1 in which a user follows the LRO satellite while displaying lunar nomenclature labels.
The Lunar Reconnaissance Orbiter team likes to keep it running up on a screen at their office
It used to work fairly consistently across devices, after some initial loading lag, but lately I’ve been running into more performance issues.
Attached is the webgl report from my iphone. (it does not support webgl2)
