Hacker News Reader

Comment by m3at | Hacker News Reader

As mentioned in the article Godot has a low processor usage mode:

> If true, the engine optimizes for low processor usage by only refreshing the screen if needed

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

I'd love to see a comparison of a simple application, e.g. a media player in Qt vs Godot using this mode, and see which one drains a laptop battery quicker.

A media player is a bad choice since it usually requires a very specialized library.

Even better. The comparison is of the GUIs themselves anyway.

Have both use the same specialised libraries.

If anyone wants inspiration, Winamp is the gold standard for media players with excellent GUI bling and skinning.

This makes no sense to me.

If your test involves two different GUI systems running the same 'specialised libraries', you are running the specialised libraries, not the GUI systems.

A media player involves heavy crunching and streaming and memory I/o, and access to the GPU if possible - these things that game engines excel at.

Most GOOD game engines are in fact an entire operating system, abstracting away the host operating system, and attempting to depend on it very minimally - giving coders an environment which does not have to conform to "business user" semantics.

This doesn't mean game engines don't burn through energy. But on mobile, at least, most of the good game engines do allow you to fine-tune your frame-rate such that, indeed, you don't need to update anything - video or stream - at all unless some event happens..

It would be an interesting test - but beware that there are multiple approaches, and even plain ol' definitions, for how a 'game engine' differentiates from an 'operating system'.

The two systems of thought have been intertwined, commercially, for decades...

A simple A/B test of the sort I described is fairly common. Especially when we are considering alternatives and want to isolate one variable, eg the GUI. Eg if someone was interested in godot and qt was the usual then I'd encourage that team member to use the same media libraries is a given to keep it fair. This is basic science methodology: change one thing at a time to enable comparison.

You'd be amazed how much overhead a change can introduce even if the real work is done by a dedicated library. This is the whole point I was making.

eg A library like imgui that repeatedly redraws itself isn't actually that wasteful power wise if you tune it and make it fit for purpose. We've done exactly that for mobile. The simplicity of its approach enables all sorts of optimisations. Imgui is a straightforward animal that can be optimised in all sorts of directions, that is actually one of its drawcards. Reorientating it to output text has already been done - thats how flexible it can get.

Not sure if media player is the best choice, since playing a video is similar to a game and I guess that most of the battery power goes into decoding and displaying the video not the surrounding gui for play buttons and the like.

I would rather see how they fare with a classic GUI like a text or spreadsheet editor. Maybe for simplicity sake a calculator or an IRC client, then you just have to join an active channel and let it run for a while.

... you're 100% right, I meant to say music player. Basically the idea is to have something that does have to run in the background constantly, with some updating UI elements (e.g. position slider), but doesn't use too much battery on its own. The issue with a text editor is that unless you have some automated way of entering text it may be hard to compare the two. IRC is maybe not a bad idea.

Why would any engine re-render if it's not needed? It will still have benefits even on desktops.

If it's built with the assumption it needs to throw it all away because every frame SOMETHING should change, why take the time to figure out dirty flags or the like.

It's more efficient to assume that things change when designing for systems that constantly change (i.e. video-games).

I think mostly because having scads of clever conditionals all over the place greatly increases the risk of subtle and hard-to-reproduce bugs. From a 2007 Carmack email [1] :

> The way we have traditionally measured performance and optimized our games encouraged a lot of conditional operations -- recognizing that a particular operation doesn't need to be done in some subset of the operating states, and skipping it. This gives better demo timing numbers, but a huge amount of bugs are generated because skipping the expensive operation also usually skips some other state updating that turns out to be needed elsewhere.

> We definitely still have tasks that are performance intensive enough to need optimization, but the style gets applied as a matter of course in many cases where a performance benefit is negligible, but we still eat the bugs. Now that we are firmly decided on a 60hz game, worst case performance is more important than average case performance, so highly variable performance should be looked down on even more.

There was fascinating breakdown [2] of a single GTA V frame about five years back. It was a real eye-opener for me - whole full-screen rendering passes for things like water reflection and refraction when there isn't even any water visible in the scene.

[1] http://number-none.com/blow/john_carmack_on_inlined_code.htm...

[2] http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic...

Also, modern processors might run the code anyway and trow away the path not taken. Its better to optimize by generating a function that does not have branches.

I don't think that applies to conditional rendering, does it? You can't speculatively execute a graphics API command buffer submission and then dash after it shouting "wait, come back, I didn't mean it". Same with any kind of I/O, I'd think.

You are correct. But the same strategy can be used for optimization. Eg. get rid of the whole if block, and preferably dependencies to make it pure so that it can be further optimized by caching the output. Although cpu can be faster then cache so always measure.

That only happens for a few consecutive instructions at most.

In most games, things change every frame: Physics, particles, NPC moving around, environment animation (water, "fake" wind, ...). In this case, testing for change would be a huge overhead with minimal benefit.

Practically speaking you always need to rerender. If nothing is changing then either the game is paused or you're not playing the game (equivalent to paused).

Today I learned, thanks for the link.

Reply on news.ycombinator.com