3 ms·

Dear ImGui doesn't have a "graphics engine", the actual rendering is done by user-provided code which maps vertex- and index-arrays, and draw commands to system

Dear ImGui doesn't have a "graphics engine", the actual rendering is done by user-provided code which maps vertex- and index-arrays, and draw commands to system 3D APIs like D3D, Vulkan, Metal, GL etc... Font handling is based on stb_truetype.h, but can be replaced with FreeType: https://github.com/ocornut/imgui/blob/master/misc/freetype/README.md https://github.com/ocornut/imgui/blob/master/misc/freetype/R... In any case, versatile text rendering is certainly not the design focus of Dear ImGui (AFAIK there's also no support for RTL layout), instead it is mainly targeted at quickly creating specialized UI tools (especially inhouse tooling for game development), less at creating end-user applications. There's plenty of UI frameworks to create "end-user applications", but hardly any that fill the specific niche served by Dear ImGui.

spookie 2y ago
There is microui if you want another one. Much more barebones as the name implies, but very easy to extend! Pleasant even if a bit quirky. Also nuklear, but haven't really gone much in depth with it.
- flohofwoe 2y ago
  I have some experience with both :) https://floooh.github.io/sokol-html5/sgl-microui-sapp.html https://floooh.github.io/sokol-html5/sgl-microui-sapp.html https://floooh.github.io/sokol-html5/nuklear-sapp.html https://floooh.github.io/sokol-html5/nuklear-sapp.html IMHO Nuklear goes a bit too much into the 'immediate mode design purity' direction which makes it a bit less convenient to use than Dear ImGui. Microui is indeed a very minimal UI, but might be useful for just adding a small controller UI (similar to dat.gui in the JS world).
  - jayshua 2y ago
    Could you expand a bit on 'immediate mode design purity'? I've done immediate mode stuff from scratch and my experience had been "just write whatever code you need to get it to work," there hasn't really been an overall architecture guiding it. Never worked with an im library before.
    - flohofwoe 2y ago
      Looking at the Nuklear example code again it turns out that I was remembering wrong. I seemed to remember that Nuklear requires to store persistent state on the API user side and pass that into the Nuklear functions, but this was actually microui 1.x (which also has been fixed in the meantime in microui 2.x). Sorry about the confusion. E.g. in microui 1.x defining a window worked like this: static mu_Container window; if (mu_begin_window(ctx, &window, "Style Editor")) { ... } ...in microui 2.x it's no longer necessary to store the window state on the user side: if (mu_begin_window(ctx, "Style Editor", mu_rect(350, 250, 300, 240))) { ... }

spookie 2y ago

There is microui if you want another one. Much more barebones as the name implies, but very easy to extend! Pleasant even if a bit quirky. Also nuklear, but haven't really gone much in depth with it.

flohofwoe 2y ago
I have some experience with both :) https://floooh.github.io/sokol-html5/sgl-microui-sapp.html https://floooh.github.io/sokol-html5/sgl-microui-sapp.html https://floooh.github.io/sokol-html5/nuklear-sapp.html https://floooh.github.io/sokol-html5/nuklear-sapp.html IMHO Nuklear goes a bit too much into the 'immediate mode design purity' direction which makes it a bit less convenient to use than Dear ImGui. Microui is indeed a very minimal UI, but might be useful for just adding a small controller UI (similar to dat.gui in the JS world).
- jayshua 2y ago
  Could you expand a bit on 'immediate mode design purity'? I've done immediate mode stuff from scratch and my experience had been "just write whatever code you need to get it to work," there hasn't really been an overall architecture guiding it. Never worked with an im library before.
  - flohofwoe 2y ago
    Looking at the Nuklear example code again it turns out that I was remembering wrong. I seemed to remember that Nuklear requires to store persistent state on the API user side and pass that into the Nuklear functions, but this was actually microui 1.x (which also has been fixed in the meantime in microui 2.x). Sorry about the confusion. E.g. in microui 1.x defining a window worked like this: static mu_Container window; if (mu_begin_window(ctx, &window, "Style Editor")) { ... } ...in microui 2.x it's no longer necessary to store the window state on the user side: if (mu_begin_window(ctx, "Style Editor", mu_rect(350, 250, 300, 240))) { ... }