Increase CesiumJS performances on Integrated graphics

CesiumJS
1

We need to support target platforms with no dedicated GPU and only Integrated graphics (Intel 5xx/6xx/…)
We are hitting some performances bottlenecks when viewing multiple (a few dozen) large polygons/ellipsoids/polylines as well as Entities with billboards and labels. Entities are stored in CustomDataSource and can be moved by an external source (through entity.position).
Currently, the scene FPS can go under 20 when static, and under 10 when entity billboards and some polylines are being moved.
I have searched and read about increasing performances in Cesium on the Forum and on Google groups and tried to apply advices I found but currently find myself out of ideas.

Here are some details on our currently applied configuration:

  • Skybox, sun, moon, ambientOcclusion, dynamicAtmosphereLighting, terrain shadows, shadows, allowTextureFilterAnisotropic, FXAA and bloom are disabled
  • webgl configuration : webgl: { alpha: false, stencil: true, premultipliedAlpha: false, preserveDrawingBuffer: false, failIfMajorPerformanceCaveat: false, antialias: true, depth: false, powerPreference: “high-performance” }
  • Elevation is a basic default Ellipsoid WSG84
  • Use ArcType.NONE on primitives when possible
  • Chrome seems to get better performaces than Firefox
  • We tried adjusting the viewer.resolutionScale dynamically (between 0.5 and 1) based on the FPS value during high load, which helps slightly at the cost of visual quality.
  • The viewer requestRenderMode is set to false. I am assuming that rendering even more infrequently is not something needed right now.

On a similar target platform, viewing this sandcastle example fullscreen Cesium Sandcastle with the Cesium Inspector ( viewer.extend(Cesium.viewerCesiumInspectorMixin) ) I get 15-20 FPS.

Any advice on how to get more performances on a target with Integrated graphics would be welcome. I am also looking for CesiumJS benchmarks in order to have a basis for comparison.

2

I think that is structural problems of cesium. And also its about integrated graphic cards, they are use more memory than new generation graphic cards.

3

Would using primitives as described here help? Custom Geometry & Appearances – Cesium

4

There are some good ideas here that could be applied, but it would require quite a lot of workarounds and I am not sure that the static aspect of Primitives fits our use cases very well.
We already use Primitives for some specific objects that are created once.
But most of our geometries should be added/removed/moved/updated independently at run-time. The issue is that changing one instance (add/remove/update/move) forces to re-create the whole Primitive (all the instances): https://groups.google.com/g/cesium-dev/c/fUjneJlmgTs
Since the add/remove/update steps are rarer than our move events it would be OK for those to be costly, but moving can happen quite frequently on one Geometry, and re-creating the whole Primitive (holding all the instances of one Geometry type) on each movement does not seem like a good idea.

Someone can correct me if I am wrong, but I did not manage to find a way to update the modelMatrix of only one instance in a Primitive geometryInstances

Some smaller but existing issues:

  • Our geometries need to display a label, available in the Entity API, but not directly within a Primitive API level (I would need to maintain some sort of separate LabelCollection)
  • They can also have different visual appearances, but here concessions can be made in the sake of performances.
1 Like