Reducing Cesium CPU usage (was: Do you use Google Earth?)

[Kevin Ring]

> Can we cleanly and efficiently detect changes in commands?  I think so.  Is it the most robust, centralized, and future-proof place to do detection?  I think so.  Will some users also want higher-level coarse-grained checks that can fully eliminate the render loop in niche cases?  I think so.

Ok, that definitely sounds worth investigating.

To my way of thinking, though, stopping the render loop entirely is pretty valuable, and we should do it whenever we can.  Obviously there will be a lot of cases where we can't.  I'm guessing that's what you meant by niche - it'll be rare-ish that can fully stop it?

I also want to try dynamically adjusting the frame rate in the cases where we do need to render.  When interacting with the globe we want a smooth 60 FPS.  Otherwise, we can probably get away with 30.  With a real-time clock, 5-10 might be plenty for most applications.

Kevin

On Mon, Feb 9, 2015 at 12:18 PM, Patrick Cozzi <pjc...@gmail.com> wrote:

> Maybe Skype sometime?

OK, will email you.

> You'll have to tell me more about what you mean by handling it at the command level.

Basically all Cesium does is issue commands that the renderer interprets and issues WebGL calls for.  If a frame generates the same commands (including the same buffer, texture, etc. contents), then the scene didn't change.  We still need to execute update(), but we don't need to execute commands, which chews up a lot of CPU (including in the browser itself) and all the Cesium-related GPU work.  Can we cleanly and efficiently detect changes in commands?  I think so.  Is it the most robust, centralized, and future-proof place to do detection?  I think so.  Will some users also want higher-level coarse-grained checks that can fully eliminate the render loop in niche cases?  I think so.  What exactly do we do?  I don't know yet.

Patrick

On Sun, Feb 8, 2015 at 5:34 PM, Kevin Ring <ke...@kotachrome.com> wrote:

Hi Cozzi,

Sounds good.  Maybe Skype sometime?  It's been awhile!

Day lighting shouldn't be a problem in my approach, because it should only change if simulation time is advancing.  Currently (though maybe we can do better) the Cesium clock ticking keeps the scene rendering.

Water, and other things that change as a result of wall clock time rather than simulation time, are trickier.  The obvious approach is to drop the frame rate,  without stopping rendering entirely, when we detect that this sort of thing is the only reason to render.

You'll have to tell me more about what you mean by handling it at the command level.

Thanks,
Kevin

On Feb 9, 2015 3:25 AM, "Patrick Cozzi" <pjc...@gmail.com> wrote:

Thanks for all the feedback.

@Kirk - we made some progress on declutter for a ESA Summer of Code in Space project.  Search the forum and check out #1097.  I don't think you will find useful code, but there are ideas and papers that could be useful.  We will address this in core Cesium at some point since I expect it will become increasingly important for KML.

@Kevin - we should sync-up on the idle optimization for issues like shader-based animated water and day lighting, and if the optimization can be handled the command level.  If not, I think robustly supporting it in the general case will be hard, but perhaps a 95% solution will be fine for most.

Patrick


On Wednesday, February 4, 2015 at 12:41:37 PM UTC-5, Kirk A wrote:

I haven't noticed the automated declutter of mouse-billboard(pin) interactions. GE did this automatically. As we are migrating to Cesium, we have missed this. In fact, we have just recently implemented our own mouse event handlers; the examples helped, but the differing 'movement' structures were initially puzzling. As far as the actual declutter, we haven't implemented that yet. Is there a stock function that we've overlooked?

-Kirk

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "cesium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cesium-dev/pELFFInBzy8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

twitter.com/pjcozzi

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

www.kotachrome.com/kevin

[Patrick Cozzi]

> To my way of thinking, though, stopping the render loop entirely is pretty valuable, and we should do it whenever we can.

Agreed.

> I'm guessing that's what you meant by niche - it'll be rare-ish that can fully stop it?

Yes.

> I also want to try dynamically adjusting the frame rate in the cases where we do need to render.

Yes.  We may be able to borrow ideas from progressive rendering and even explore things like dynamically lowering the resolution when doing fillrate-bound operations (kinda rare in Cesium though).

Patrick

To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "cesium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cesium-dev/pELFFInBzy8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to cesium-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

twitter.com/pjcozzi

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

www.kotachrome.com/kevin