Cesium CPU Usage

CesiumJS
1

Hi all,

We have begun tackling the issue of performance and CPU usage of Cesium, specifically in regards to the frame rate and minimizing rendering when not necessary. We plan on breaking this task down into phases.

Initial Effort: This will cover the most common use cases for a cesium app: loading in terrain, imagery, and data. This new performance behavior will be opt in. The philosophy here is based on the assumption that the developer at the app level knows best where requests for a render frame are needed. There will be a public method you can call to request a render based on changes your app may need if you do opt into this more performance based mode. For example, when in this mode, turning on and off fog during your app, or changing the color of a primitive via the API will not trigger rendering a new frame automatically.

Later Effort: The plan at a later time would be to dive more deeply into the render and only trigger changes when the view itself changes. This requires a more extensive update, but changes to the lower level APIs (for example showing and hiding a primitive) would request a render frame automatically.

We are interested in hearing your input and any specific use cases you have in regards to Cesium CPU usage. Please let us know your thoughts!

Thanks,

Gabby

2

Hi Gabby,

We have some hacky code in OL-Cesium (https://github.com/openlayers/ol-cesium/blob/master/src/olcs/autorenderloop.js) to automatically render/suspend Cesium.

It is not clear to me if everything there is covered by the "initial effort". Notably, tweens, camera position, camera methods interception and navigation.

Anyway, it will be a great improvement to have some support in Cesium.

Thanks,
Guillaume

3

Hi Guillaume,

We did get to review the OL-Cesium implementation and it definitely factored into the planning process. Our goal in the initial implementation is, when the performance optimization is enabled, to allow the developer to have the rendering loop updates tied to specific events (like here in OL-Cesium) that are specific to that application and how it uses Cesium.

Entirely handling camera movement will most likely be handled in phase 2. Updating on a change to the camera position, direction, up, right, or frustum properties would capture any of those other camera methods.

Thanks,
Gabby

4

An initial pull request is open on GitHub, we’d appreciate any input, reviews, or feedback!

Thanks,

Gabby