Performance: No rendering if invisible & lazy sync about ol-cesium HOT 19 CLOSED

Monday decission: let's go for simple ol.View detaching and Cesium rendering stop.
Then let's create PR with it. Further improvements to be discussed later (after basic PR is merged).
Let's call: map.setView(null);

from ol-cesium.

The problem with this approach is, that after calling map.setView(null), all the ol controls stop working. This would also happen if we were to create a copy of current ol.View (because the controls would be modifying the copy and thus having no effect in 3D).

from ol-cesium.

Basic version done with PR #28 - but only on Cesium side.

@ahocevar please comment on possible ideal basic implementation on ol3 side.
Is modification of ol3 for this required?

from ol-cesium.

I think there is no need to change anything in ol3 for this. The following should work:

var view = map.getView();
map.setView(); // pause synchronization
map.setView(view); // resume synchronization

from ol-cesium.

@ahocevar I tried using map.setView(null), but the change of View is propagated to the controls (zoom control and rotation control) and they stop working (see #19 (comment)), although still being displayed.
I expect the exact same thing would happen when calling map.setView() without any parameter, wouldn't it?

from ol-cesium.

Good point @petrsloup. So we need to figure something out on the ol3 side.

from ol-cesium.

In ol.Map, we could introduce a boolean pauseRendering_ property with a setPauseRendering() setter as part of the API. When pauseRendering_ is true, ol.Map#render() will return without doing anything.

from ol-cesium.

Controls update their UIs at postrender time. So if the ol.Map#render function returns immediately the controls won't be updated.

from ol-cesium.

@elemoine As far as I can tell, ol.Map#render() is called by ol.Map#renderFrame_(), which dispatches the postrender event. So the controls should still get updated when ol.Map#render() does nothing.

from ol-cesium.

OL3 side is not ready for this yet...

from ol-cesium.

@elemoine, any other ideas for fixing this?

from ol-cesium.

Lets try to make all the layers invisible on OL3 - and ignore this operation in the synchronizer temporarily on OL3Cesium side (keep list of visible layers separatelly).

from ol-cesium.

Is it possible that there is also a performance penalty of Cesium trying to render the globe while we are viewing the map? Just got this from our client:

When the globe isn't being rendered, it may make sense to stop the animation timer completely. Something like:

this.animationDelay_ = goog.async.AnimationDelay(function() { 
this.scene_.initializeFrame(); 
this.scene_.render(); 
this.camera_.checkCameraChange(); 
this.animationDelay_.start(); 
}, undefined, this);

And call start/stop on the animation delay in olcs.OLCesium.prototype.setEnabled. The timer callback isn't doing much when the globe isn't enabled, but it does still spin the CPU unnecessarily (3-5% usage on my RHEL6 machine on Chrome 35).

When the globe is enabled, is it necessary to render the globe on every frame or can that be managed a little better like the 2D map? I have little experience with Cesium/WebGL so I honestly don't know the answer. My observation was that on Windows there was minor CPU usage (5-7%) even after everything finished rendering and on RHEL6 I was seeing 60-70% CPU usage (on one core) after all tiles were rendered.

from ol-cesium.

The initializeFrame() takes care of camera update and also processes accumulated user interaction events, but in our case we probably don't need to do this when the globe is not visible (it seems the camera is updated automatically when changed, so all the olcs.Camera methods should work properly even without initializeFrame calls) -- I'll look into this.

About the second note (constant rerendering): if we want to automatically "pause" the Cesium rendering, we need to know when the rendering is required (any user interaction, inertial animations, layers changed, tiles loaded, application-specific modifications to the Cesium.Scene (non-synchronized layers, objects...)), but it would be very hard (or impossible) to detect all the possible changes.

from ol-cesium.

Merged is an OL3 implementation which is using the hiding of the root LayerGroup for gaining the performance on OL3 side - this should be acceptable solution for now.

For a more proper solution on OL3 side there may be a new ticket probably.

A comment from @ahocevar in #66:
The only way I could think of for handling this in ol3 would be to give the map a setRenderer method, and create a dummy renderer that does nothing but dispatch render events. The former would be implemented in ol3, the latter could be done on the app (i.e. ol3-cesium) level if we allow applications to subclass ol.renderer.Map and implement renderFrame. Same for ol.renderer.Layer and prepareFrame.

from ol-cesium.

Reopening based on feedback from our client:

The globe is no longer rendered when it is not enabled, but I'm still very concerned with rendering the globe on every animation frame. I noticed a significant performance impact when parsing WFS features. Using the 2D map, the application parsed 7000 features in 4 seconds. With the Cesium globe enabled, the same 7000 features took 54 seconds to parse. This is not an acceptable performance hit, and is largely caused by competing resources between rendering features currently on the map and parsing new features.

from ol-cesium.

This sounds like a problem related to the "Performance of feature synchronizer" - it is probably not as much related to this ticket (which has already 4 pull requests merged). Better to create a new ticket for this @ahocevar?

from ol-cesium.

In fact it seems to me directly related to already open ticket #70.

from ol-cesium.

@wallw-bits @schmidtk Can you please test if #72 fixes this performance issue?

from ol-cesium.