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.
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.
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.
