Hacker News Reader

Comment by jadtl | Hacker News Reader

I was trying to think of arguments against it, so I thought about the fact immediate mode GUIs might not always be suitable, before I stumbled upon this post: https://stackoverflow.com/questions/47444189/what-are-the-pe... The only other downside I can think about is from a design standpoint, the application has to have the same design language across platforms, so it cannot have a native look for each. Any other cons?

View on HN

I’ve been thinking about this a bit and the main concern I’ve had is around accessibility. The web has had a lot of iteration over time to make it relatively easy to build applications that are well suited for use with screen readers and other assistive technologies. Have you done any testing along those lines with the Godot UI tools?

Some quick googling tells me Godot doesn't have native tray icons/notifications support or access to peripherals like webcams & printers. Buut if you're using Godot over electron/flutter/QT your app is probably focusing on 3D / physics topics. You can implement plugins for those other niche desktop features as you need them.

There is some ongoing PR, so it might come at some point :

https://github.com/godotengine/godot/pulls?q=is%3Apr+is%3Aop...

I feel like the scripting language (GDScript) is pretty bad. There's no real way to handle errors and its type system sucks compared to typescript. Not to mention you lose out on the diverse packages available from npm.

I would be concerned about power efficiency / battery life considering the type of rendering it's doing. That would be cool to get some info on.

It requires a GPU.

I'm not aware of any GUI stack that doesn't require a GPU, nor any desktop hardware released over the past 30 years that didn't have a GPU.

Qt or Electron don't; they both have software renderers. The latest Godot needs a GLES 3 or Vulkan GPU. The older versions used to only need a GLES 2 GPU.

Qt and Electron output to the OS-level display APIs, where screen rendering is handled by X11, Wayland, Quartz, WDDM, etc., all of which still rely on GPUs for output.

Godot, as a game engine, bypasses the OS and uses lower-level graphics APIs like OpenGL and Vulkan. But you only need these APIs available regardless of what hardware is under them, and you can use software-based rendering with e.g. Mesa, Lavapipe, or other software renderers. With a 2D desktop application, performance should still be fine.

X11, Wayland and WDDM only use the bare minimum functionality from those APIs, so they work just fine on old DX9-level GPUs for example. Godot needs much more recent GPUs.

It's the use case that requires the bare minimum functionality. Godot might require more recent lower-level APIs than the other GUI toolkits, but if the use cases are similar, then it wouldn't require more performance out of them than the other GUI toolkits would. Using software-based implementations of those APIs would more than likely be sufficient, meaning that there's no dependence on any specific class of GPU.

I RDP or VNC into VMs that run without a GPU all day. It's very much optional for 2D, at least.

Reply on news.ycombinator.com