Unexplained very high resource usage when idle

If I run this:

...and let it sit idle, within about 60 seconds my GPU temperate is 100C and my laptop sounds like it's about to lift-off.

Contrasted with this:

Where resource usage seems to be minimal, system temperature doesn't climb at all and the laptop is silent.

The question is; WebGL apparently uses Cesiumjs internally so what is the difference? Can anyone explain what's going on here? This is a real problem..!

Thank you

*WebGL Earth, I mean!


I suspect WebGL Earth has a custom render loop so it is not rendering the frame unless the camera or an object moves. It is also possible to do this in your own Cesium app. We plan to have this as a core feature in Cesium (see #1865), but it requires some effort to do robustly.


That actually does appear to be the case. It’s implemented in https://github.com/webglearth/webglearth2/blob/30b5143af805485454aa16bcd737f16440ca9a6f/src/app.js#L202 . Some interesting logic there.

Thanks for the response and investigation guys. I think I'll have a stab at implementing that control logic myself. A large portion of our users would be low-power laptop based so saving cycles where possible is essential. Cheers

I recommend you use the render pausing logic in TerriaJS (full disclosure: I wrote it):

It doesn’t require a custom render loop and it can pause rendering even when using terrain.

Thanks Kevin, yeah, I discovered the terrain was the thing I need to consider properly!

Btw - the original 'problem' turns out it's related to dual-displays; I see the aforementioned high temp/usage on the primary display but not when I have the Cesium window on the 2ndary display. 2015 Macbook Pro/Mavericks - very strange. Thought you might be interested to know. Thanks for the code, will look at integrating anyway.

All of our macs fans startup when running Cesium. Temperature apps show big increase in heat. Does not seem to matter what app or what screen if duel screens.

Yeah, I wouldn’t expect any difference based on the screen. Without code like that in TerriaJS or WebGL Earth, Cesium renders as fast as it can (up to the browser limit, usually 60 FPS) and it’ll burn whatever CPU / GPU is necessary to do that.

Eventually we’ll have render pausing logic in Cesium itself but there’s no ETA on that.

I notice that you guys also use a custom render loop in doarama and recently i visited some redbull page that featured an event using doarama.
It was my impression that performance of doarama was better than my own app that do some tracking of entities also.

I see in other posts that cesium team do not recommend custom render loops. Kevin, could you share some of the motivation of you guys using a custom render loop, possible share any insight/experience you guys have from building cesium apps that actually reach a lot of people/devices. Tips and tricks that you have done to make your apps perform better if any ect.

Hi Poul,

In general I don’t think custom render loops are necessary, and they won’t really provide any performance improvement. Cesium’s preRender and postRender hooks generally give you all you need to do any custom render-time processing. I think that Doarama uses a custom render loop primarily because that code was written before Cesium even had preRender and postRender. Hopefully Chris Cooper will chime in if that’s wrong since I haven’t worked on Doarama myself (I’m only a fan, and I sit next to Chris at work, but he’s not here at the moment or I’d ask him!)…

The other thing about Doarama, though, is it doesn’t use the entity system. Partially that’s because it was written before there was an entity system (seeing a pattern?) but partially it’s because Doarama does some tricky things and wants a level of control that is not possible with entities. For example, I believe the GPS tracks are rendered as completely static polylines, and a custom shader with time passed in as a uniform makes the line appear incrementally over time.



What specific part do I need to add for the render pausing logic to happen?


ok i think i figured it out.

for others:

this is mostly related to lines 593-628 and lines 422-428, and then adding a few listeners to mouse movement and screen resizing.

Gerry - you may be better off starting a new thread and posting your KML file if possible.