If I were you, I would rather start with SQL. It is so pervasive that it would never be a skill you regret having. I don’t believe you would regret learning EdgeQL either, or any skill for that matter, but in terms of priority I would suggest SQL would be a safer bet and help you contextualise other querying approaches down the way.
Probably a decent chunk of the perceptual issue you're seeing comes from their choice of font rendering library, which is noticeably "the IMGUI font rendering library", and looks amateurish. This is stb_truetype, which is a very primitive library, but is easy to install and incorporate. The other library is freetype+harfbuzz, which produces higher quality output, faster, and with lower memory. The cost of freetype is that installation is absurdly difficult, the maintainer is offensive, and the code is ancient, unreadable, and architecturally a disaster.
I don't think the chosen GUI library causes the other UI issues you perceive. The author probably hasn't put much time into learning visual design, and thus fell into whatever the UI library supported. But to produce a better one, the author would have had to do a lot more learning and thinking, which is independent of the library choice.
> There is literally no downside to using the IMGUI concept
There's a big downside, the performance penalty. For a GUI that renders moderately complex objects, the cost of not caching becomes overwhelming, the equivalent of losing 20 years in GL architecture advances. Pushing the VBO to the GPU each frame is the same as losing indexing. My own application doesn't render at 60 fps in immediate mode.
I find that people who believe that IMGUI is somehow faster than RMGUI are game developers who have been taken in by marketing, because basic knowledge of GPU programming (i.e. what is indexed rendering) is enough to see that this couldn't possibly be true. Their UIs are usually simple enough that the performance penalty is not important. And many RMGUIs have heavy styling, visually incomparable to their IMGUI counterparts, which makes the average RMGUI far heavier.
I'm not a graphics programmer, and don't understand the specifics of how a modern GPU works.
I can state from experience that using Dear ImGui over Qt massively sped up the application we developed (Media player with non-trivial UI that decoded RAW video in real-time using CUDA/Metal/OpenCL).
Framerate increased by around 10%, and there was no longer any significant difference between the consumer-oriented software and an internal engineering tool that was literally nothing but an SDL window and some direct API calls.
Perhaps caching was performed driver-side, or perhaps maintaining indexing is not a huge issue on modern GPUs. I couldn't tell you, honestly, but I saw the performance gains with my own eyes. Entire UIs would chew up less resources than a blank QWindow.
I think "media player" is one of the best cases for ImGUI's, as they whole frame changes every time.
The RMGUIs (should?) be much more efficient when the contents are both hard to render and don't change much -- think large amount of styled text, or detailed SVG diagram, or a graph.
(and blank QWindow consumes 0% CPU when there are no screen updates -- this would be hard to beat with IMGUI's even with the best GPU)
> I saw the performance gains with my own eyes. Entire UIs would chew up less resources than a blank QWindow.
I already mentioned this: "many RMGUIs have heavy styling, visually incomparable to their IMGUI counterparts, which makes the average RMGUI far heavier". Dear IMGUI will be faster than the average RMGUI implementation. It's doing way less work. In addition to being cleaner internally.
For simple use cases, Dear IMGUI behaves like an RMGUI internally. (flohofwoe mentions this in another thread.) So its only performance impact is some minor caching overhead, which is far smaller than extra GPU work.
