Haystack
I suspect the problem there is that godot has to support a half-dozen or more operating systems, so any interface with the operating system has to be the least common denominator of all systems (including html). The developers have tried to make it as independent as possible, to avoid problems with new exports or changes to APIs. The exceptions are usually minor things like accelerometers.

Edit: There is a low processor mode intended for non-game applications that reduces the background activity.

      I don't want to be rude, but please actually read the documentation I gave you. It explains it clearly.

      It may be easier if you watch this video. Godot is based on event driven programming, so you use event handlers and signals to deal with events or asynchronous events. Very rarely, if ever, would you use a while loop, because it will most likely freeze your game, like I said.

        Previously I wrote "I seem to recall reading there was a way to do this, but now that I need it, I can't find where I read that." This is what I was thinking of: "Project >> Project Settings >> Application >> Run >> Low Processor Mode".

        https://docs.godotengine.org/en/stable/classes/class_os.html

        "If true, the engine optimizes for low processor usage by only refreshing the screen if needed. Can improve battery consumption on mobile."

        duane Yes, "low processor mode" was what I was thinking of. Thanks!

          cybereality

          Very rarely, if ever, would you use a while loop, because it will most likely freeze your game, like I said.

          I think you are misunderstanding what I meant. I think that you think I want to put that "while" loop inside one of my node's callbacks. I do not want that. I agree with you that that would be bad.

          My point was that something like the "while" event loop exists somewhere inside the Godot core, and there exists some way to configure it (e.g. one or more Godot project settings) so that it will sleep until the next event instead of just looping as fast as it can.

          The Godot Editor (written in Godot) does not consume extra CPU cycles when you aren't typing or mousing (or debugging). But some of the very trivial demo projects I've downloaded do consume CPU even when you don't interact with them.

          I'm trying to learn how best to minimize the amount of CPU/GPU that my app consumes when it doesn't have anything useful to do. (When there are no animations playing, no music, no UI events, etc.)

              Haystack My point was that something like the "while" event loop exists somewhere inside the Godot core, and there exists some way to configure it (e.g. one or more Godot project settings) so that it will sleep until the next event instead of just looping as fast as it can.

              If you look in the documentation, the main loop is an abstract class that inherits from SceneTree (Edit: correction below !). The main loop is started when the program starts, and when the main loop ends, the program ends. The main loop in my renderer does the same (though it is ludicrously much simpler), and I believe any such thing on a Turing machine that starts and controls a time depending system like a game, or simulation that calculates stuff periodically does it (ready for correction).

              When you say "as fast at it can" I think there are several misconceptions in there.

              First, assuming not a headless system (a server that does not display but just calculate) there is rendering. The "speed" (frame rate) depends either on the refresh rate of the monitor (aka vsync, switch it on !), as fast as it can (but then the drivers or program may start to optimize things away when it becomes clear that a frame in flight will never see the light of day, "my pc makes 500 fps !" is a nonsensical statement), or things in between with modern monitors (in Vulkan they are named presentation modes). So, if you switch on vsync, the rendering part of the main loop will only be called after the monitor signalled "give me the next frame". This is done every 60th of a second or every 144th in fixed modes. With many games this is only a small fraction of what a processor can do, and it is usually only one thread, out of 16 or more on modern PC processors. You're pretty close to idle power consumption most of the time.

              Second, the main loop may call other functionality, and start concurrent functions, physics processing for instance that needs a different, fixed(!) tact or else numeric catastrophe :-). The main loop may and must, if values are needed, synchronize these things, for that it must run. You will need a controlled way to pause and resume it, or else gamers walk out on you with the pitchforks in their hands shouting "much wrong, many anger, such error !" :-)

              Suggestion is, let the game engine do its thing and make a game without pondering the intestines of Godot, or, if you wish to try, write your own framework, which is a very nice finger exercise :-), and probably makes you come back to the engine after a year or 2, more clever than before :-)

              Edit: On a PC, do NOT overclock if you don't really need it. That's the energy hogs. Mine rises from around 70W to >400W. On a mobile, switch off network and bluetooth or even to flight mode because driving an antenna is energy intensive, more than what the rest of the electronics need.

                  Haystack The Godot Editor (written in Godot) does not consume extra CPU cycles when you aren't typing or mousing (or debugging). But some of the very trivial demo projects I've downloaded do consume CPU even when you don't interact with them.

                  Demo projects don't necessarily use optimal code. They often keep it simple for teaching purposes.

                    So doing the main loop while thing is possible, but it doesn't seem like it's of any use for a game. I could see why you might want it for a headless server, or other type of business applications. For a game, it doesn't make sense. There would be very rare times, if ever, you have a game without animation, without music, without any code running, etc. It's just not a realistic use case. Even if the screen is static (for example, with some type of 2D GUI interface) the frame still needs to be updated at 60 fps. Perhaps you can stop the buffer from clearing and just leave the last frame, sure, but you still need something alive to respond to input and restore interactivity. If done correctly, it could improve CPU utilization, I believe this is how the Godot editor works. But, again, in a real game this use case is almost non-existent. But it depends what you are doing, maybe I misunderstood your project. But if I understand correctly, this seems like a premature optimization.

                      cybereality There would be very rare times, if ever, you have a game without animation, without music, without any code running, etc.

                      no physics processing... But if I understand the OP correctly they might be looking to develop something very similar to Heroes of Might and Magic III, that kinda worked like it.

                      @Haystack it might also be worth considering that in godot you can just pause/disable processing per individual script attached/scripted node. As an optimization that might be more relevant. That applies to both process() and physics_process(), you do have to toggle them individually iirc.

                        Pixophir

                        or, if you wish to try, write your own framework, which is a very nice finger exercise

                        Been there, done that. :-) I'm new to Godot, but not to game programming in general. (I'm certainly no expert, but also not a novice) Which is why I'm reasonably sure that Godot can do this, b/c it's pretty basic.

                        I haven't tested this yet, but the way I think it works is: if any of the nodes in the scenetree have a _process() or _physics_process() callback, then Godot will call them every frame, so it has to wake-up every frame. But if no nodes in the tree have those callbacks, (or if the node disables processing), then Godot won't run process or physics tasks at all, and will sleep until the next event.

                        I think the sample code I downloaded was so CPU intensive was b/c it has a _process() function.

                          So you are somewhat correct. Defining _process, even with nothing in it (just pass) does consume cycles. If you have a blank script attached, with nothing else, I am getting around 9,000 fps. With a script with:

                          func _process(_delta):
	pass

                          Then it is 8,000 fps. But this sounds like more than it is (because of the way fps is measured) so the difference is not much. And with vsync at 60 (or even 144) this is far above any sort of useful metric.

                          If you additionally do this:

                          func _ready():
	set_process(false)

                          Then performance is even greater, around 10,000 fps. This would seem like a better way to do it, rather than attempt to turn Godot into something it is not.