6 ms·

I did an Ask HN [1] about this topic a little while ago. Most relevant comment [2], from gunibert is here: The problem in a framework like GoDot is, that it i

I did an Ask HN [1] about this topic a little while ago. Most relevant comment [2], from gunibert is here: The problem in a framework like GoDot is, that it is meant for Games. A game renders screens in 30/60 fps. A Desktop application like a Gtk application does exactly nothing if you dont interact with the application. If you click a button only the button gets re-rendered. This is more efficient then using something like a game engine which has no concept about damaged regions and so on. Also, people like to have something like "native" look and feel. This would be possible with Java-SWT as it abstracts away the toolkit. This is possible but in the case of SWT it is just broken (think about margins, text, scroll behaviour). The other option is to use electron as it is just plain simple, works even in the web (you can basically make a webapp and repackage that as an electron app) Or you package a toolkit with your application and avoid native libraries. This happens in the world of Qt for example. Gtk is cross-platform too but not statically linkable. [1] https://news.ycombinator.com/item?id=23580213 https://news.ycombinator.com/item?id=23580213 [2] https://news.ycombinator.com/item?id=23584258 https://news.ycombinator.com/item?id=23584258

m3at 6y ago
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?#class-os-property-low-processor-usage-mode https://docs.godotengine.org/en/stable/classes/class_os.html...
- Shared404 6y ago
  Today I learned, thanks for the link.
- ladberg 6y ago
  Why would any engine re-render if it's not needed? It will still have benefits even on desktops.
  - runevault 6y ago
    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.
  - wraptile 6y ago
    It's more efficient to assume that things change when designing for systems that constantly change (i.e. video-games).
  - mrec 6y ago
    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.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... [2] http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/ http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic...
    - z3t4 6y ago
      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.
- bscphil 6y ago
  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.
  - novok 6y ago
    A media player is a bad choice since it usually requires a very specialized library.
    - rs23296008n1 6y ago
      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.
      - fit2rule 6y ago
        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...
        rs23296008n1 6y ago
        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.
naikrovek 6y ago
Game engines very much do understand efficient rendering techniques, and if they don't, you can usually easily extend them to have that capability, sometimes without even writing any code to do it.
- naikrovek 6y ago
  Not sure why I was downvoted for this, but it doesn't matter. If you want your game engine to be useful, it needs to perform well. It doesn't matter if your engine is home grown and only for your application, or if it is something you license to other developers. If it is to be useful, it needs to perform well. So, they do. Game engine developers are not stupid.
jfkebwjsbx 6y ago
> This is more efficient then using something like a game engine which has no concept about damaged regions and so on. A game engine can avoid redraws trivially if no relevant input/event has occurred. Further, AFAIK some graphic APIs do support dirty rectangles too, but to be honest, for desktop/laptop GUI apps I doubt it matters compared to anything else going on in the system. And GUIs runs perfectly fine on integrated GPUs, further reducing the cost. Blender does this perfectly fine, for instance.
slmjkdbtl 6y ago
It's perfectly reasonable to build a game engine that's possible to build these GUI-specific systems on top of (if you want lazy UI rendering simply don't call the update. For godot I believe the biggest block is the editor cuz it's geared towards game creation (haven't used godot for a while don't know anything about its usage without editor)
- Shared404 6y ago
  I actually did a POC project in Godot, it was a pretty good experience overall. There's lots of superfluous stuff if you're making tools instead of games, but it doesn't really get in the way. Edit: It was in the editor, just realized I didn't explicitly mention that.
- follower 6y ago
  > For godot I believe the biggest block is the editor cuz it's geared towards game creation Recently Godot gained the ability to selectively remove features from the editor: * https://godotengine.org/article/godot-32-will-allow-disabling-editor-features https://godotengine.org/article/godot-32-will-allow-disablin... * https://docs.godotengine.org/en/stable/classes/class_editorfeatureprofile.html https://docs.godotengine.org/en/stable/classes/class_editorf... The documentation describes it like this: """ When disabled, the features won't appear in the editor, which makes the editor less cluttered. This is useful in education settings to reduce confusion or when working in a team. For example, artists and level designers could use a feature profile that disables the script editor to avoid accidentally making changes to files[...] """
- deleted 6y ago
  [deleted]
lewispollard 6y ago
Last time I used Godot, the editor itself had a little indicator showing if the editor was redrawing or not (if it was redrawing, a little spinner appeared). And, indeed, if you leave the editor alone with only still elements, it doesn't redraw. I think that's an optional settings now. But if the editor can do that, why not the applications you make in it?
pritovido 6y ago
We use "dear imgui" for fast prototyping, some of those prototypes got to be production software. At first we were worried about the screen always updating and consuming so much energy, but reading the code it became obvious that it was extremely simple to fork the imgui with a very small update screen change, so it only updates when we do something. Imguis and game engines are much simpler to code than conventional GUI because you don't need to handle so much state.
fit2rule 6y ago
>game engine which has no concept about damaged regions Sorry, just: no. Game engines which don't handle rectangle updates are poorly designed junk. BTW, most game engines do keep track of regions needing update - its one of the most important aspects of performance tuning, for any app which presents objects on a screen to the user. Usually, the OS is doing this for an app in the apps own context - game engines also do this, and if they don't do it well, they get passed over for better-performing engines. (Disclaimer: contributor to the MOAI game engine, which does this very, very well, and which is an amazing way to do a UI - for any app..)
- Shared404 6y ago
  I've been made aware after posting this comment. I just figured that I'd share what appeared to be a useful comment from someone else the last time I participated in a discussion about this, I'm glad I did as I now have a number of further resources to do better research. Also, just took a look at MOAI, it looks pretty cool, I'll have to add it to the list of things to play with when bored.
  - deleted 6y ago
    [deleted]
- p0nce 6y ago
  MOAI does seem very cool. I like Godot for 2D but having used it for 3D I'm a bit weary with bugs there.
pkphilip 6y ago
Or you can use a Lazarus IDE which is very fast to develop in, generates native cross platform binaries which are very fast and also tiny. https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
- rcarmo 6y ago
  I tried Lazarus a few times and even though I spent a _long_ time writing Pascal, it's just not there yet. At least on the Mac, just getting it to install and run was a big pain.
  - pkphilip 6y ago
    The latest version is actually quite stable. I use this on Linux though

m3at 6y ago

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?#class-os-property-low-processor-usage-mode https://docs.godotengine.org/en/stable/classes/class_os.html...

Shared404 6y ago
Today I learned, thanks for the link.
ladberg 6y ago
Why would any engine re-render if it's not needed? It will still have benefits even on desktops.
- runevault 6y ago
  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.
- wraptile 6y ago
  It's more efficient to assume that things change when designing for systems that constantly change (i.e. video-games).
- mrec 6y ago
  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.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... [2] http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/ http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic...
  - z3t4 6y ago
    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.
bscphil 6y ago
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.
- novok 6y ago
  A media player is a bad choice since it usually requires a very specialized library.
  - rs23296008n1 6y ago
    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.
    - fit2rule 6y ago
      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...
      - rs23296008n1 6y ago
        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.

naikrovek 6y ago

Game engines very much do understand efficient rendering techniques, and if they don't, you can usually easily extend them to have that capability, sometimes without even writing any code to do it.

naikrovek 6y ago
Not sure why I was downvoted for this, but it doesn't matter. If you want your game engine to be useful, it needs to perform well. It doesn't matter if your engine is home grown and only for your application, or if it is something you license to other developers. If it is to be useful, it needs to perform well. So, they do. Game engine developers are not stupid.

jfkebwjsbx 6y ago

> This is more efficient then using something like a game engine which has no concept about damaged regions and so on. A game engine can avoid redraws trivially if no relevant input/event has occurred. Further, AFAIK some graphic APIs do support dirty rectangles too, but to be honest, for desktop/laptop GUI apps I doubt it matters compared to anything else going on in the system. And GUIs runs perfectly fine on integrated GPUs, further reducing the cost. Blender does this perfectly fine, for instance.

slmjkdbtl 6y ago

It's perfectly reasonable to build a game engine that's possible to build these GUI-specific systems on top of (if you want lazy UI rendering simply don't call the update. For godot I believe the biggest block is the editor cuz it's geared towards game creation (haven't used godot for a while don't know anything about its usage without editor)

Shared404 6y ago
I actually did a POC project in Godot, it was a pretty good experience overall. There's lots of superfluous stuff if you're making tools instead of games, but it doesn't really get in the way. Edit: It was in the editor, just realized I didn't explicitly mention that.
follower 6y ago
> For godot I believe the biggest block is the editor cuz it's geared towards game creation Recently Godot gained the ability to selectively remove features from the editor: * https://godotengine.org/article/godot-32-will-allow-disabling-editor-features https://godotengine.org/article/godot-32-will-allow-disablin... * https://docs.godotengine.org/en/stable/classes/class_editorfeatureprofile.html https://docs.godotengine.org/en/stable/classes/class_editorf... The documentation describes it like this: """ When disabled, the features won't appear in the editor, which makes the editor less cluttered. This is useful in education settings to reduce confusion or when working in a team. For example, artists and level designers could use a feature profile that disables the script editor to avoid accidentally making changes to files[...] """
deleted 6y ago
[deleted]

lewispollard 6y ago

Last time I used Godot, the editor itself had a little indicator showing if the editor was redrawing or not (if it was redrawing, a little spinner appeared). And, indeed, if you leave the editor alone with only still elements, it doesn't redraw. I think that's an optional settings now. But if the editor can do that, why not the applications you make in it?

pritovido 6y ago

We use "dear imgui" for fast prototyping, some of those prototypes got to be production software. At first we were worried about the screen always updating and consuming so much energy, but reading the code it became obvious that it was extremely simple to fork the imgui with a very small update screen change, so it only updates when we do something. Imguis and game engines are much simpler to code than conventional GUI because you don't need to handle so much state.

fit2rule 6y ago

>game engine which has no concept about damaged regions Sorry, just: no. Game engines which don't handle rectangle updates are poorly designed junk. BTW, most game engines do keep track of regions needing update - its one of the most important aspects of performance tuning, for any app which presents objects on a screen to the user. Usually, the OS is doing this for an app in the apps own context - game engines also do this, and if they don't do it well, they get passed over for better-performing engines. (Disclaimer: contributor to the MOAI game engine, which does this very, very well, and which is an amazing way to do a UI - for any app..)

Shared404 6y ago
I've been made aware after posting this comment. I just figured that I'd share what appeared to be a useful comment from someone else the last time I participated in a discussion about this, I'm glad I did as I now have a number of further resources to do better research. Also, just took a look at MOAI, it looks pretty cool, I'll have to add it to the list of things to play with when bored.
- deleted 6y ago
  [deleted]
p0nce 6y ago
MOAI does seem very cool. I like Godot for 2D but having used it for 3D I'm a bit weary with bugs there.

pkphilip 6y ago

Or you can use a Lazarus IDE which is very fast to develop in, generates native cross platform binaries which are very fast and also tiny. https://www.lazarus-ide.org/ https://www.lazarus-ide.org/

rcarmo 6y ago
I tried Lazarus a few times and even though I spent a _long_ time writing Pascal, it's just not there yet. At least on the Mac, just getting it to install and run was a big pain.
- pkphilip 6y ago
  The latest version is actually quite stable. I use this on Linux though