MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C
github.com
github.com
WASM demo: https://floooh.github.io/sokol-html5/sgl-microui-sapp.html
Source code: https://github.com/floooh/sokol-samples/blob/master/sapp/sgl...
The renderer backend is just a bunch of C functions you need to provide:
https://github.com/floooh/sokol-samples/blob/3f4185a8578cd2b...
It's also interesting to compare the binary sizes:
microui sample (https://floooh.github.io/sokol-html5/sgl-microui-sapp.html): 79.6 KBytes compressed download
Nuklear sample (https://floooh.github.io/sokol-html5/nuklear-sapp.html): 155 kb compressed download
Dear ImGui sample (https://floooh.github.io/sokol-html5/imgui-sapp.html): 491 KB compressed download
I use pygtk and dont have to fiddle with lower level stuff
Will share source code if someone is interested, but key bits:
- had a small JS glue layer using CanvasRenderingContext2D to render
- made a `wasm32-freestanding` build to lower the wasm bundle size, which meant shimming the bits of the libc microui uses
- constant repainting (while literally nothing changes) -> constant CPU load
- some libs can skip repaints but have no concept of damage area
- bad handling of high-dpi (which also can change dynamically)
- constant repainting behaves even worse on laptops which announce 180 Hz refresh interval, which means that it drains the battery 3 times faster than 60 Hz
This doesn't explain a 100% CPU usage since requestAnimationFrame is vsync-throttled and rendering such a simple scene will do the per-frame work in a fraction of a frame duration.
And FWIW I cannot reproduce the issue in both demos (in Chrome on macOS). The sokol demo has a per-frame load of about 0.3ms per 8.333ms frame, and the demo hosted on vercel.app about 0.7ms, both pretty much within expecations.
More details:
The demo is using half-resolution on high-dpi displays (currently that's sokol-app's default setting, but not sure if that still makes sense in this day and age tbh), this half resolution amplifies all sorts of text rendering issues, and it gets especially bad when there's a fractional system-dpi-scale like 125% or 150%.
PS: another problem (maybe the main problem, even if everything else is correct) is that the demo's pre-baked font atlas texture isn't all that great since it has 'anti-aliasing' baked into the glyph pixels, and the font atlas texture has a very low resolution (glyph height is 10 pixels, which would be ok for a 'crisp' hand-drawn bitmap font, but not when the font atlas has been created from a regular TTF font, which this one seems to be).
Does this Dear ImGui demo look better on your setup? This is using the native display DPI and uses a TTF font instead of a bitmap font:
https://floooh.github.io/sokol-html5/imgui-highdpi-sapp.html
It first said "that's a ton of work" to which I said, "Really? A basic IMGUI needs a texture with glyphs. The abiltiy to draw textured rectangles with vertex colors. Scissor support for clipping. Some hit testing." and it was like, "yea, you're right", and a few mins later it wrote what I needed.
I'm not saying you shouldn't use this library.
I will mention, however, it's kinda abandonware at this point. There is some bug with the draw call iterator which does a misaligned pointer access, which, if your environment is set up to catch that, can get annoying (Zig for example panics on it). There's a github issue that some have used as reason to fork it but all the forks I tried were subtly wrong, for what that's worth.
That's sad. I'm a fan of rxi's work, including this one.
And that's okay(tm).
I think it's reasonable to just patch it yourself if it doesn't work with your other tools (Zig). Though thank you for sharing the heads up.
Cosmopolitan Libc has since integrated the bits to make OpenGL work in cross-platform binaries and it's awesome.
https://github.com/raysan5/raygui
But I found it pretty straightforward (and satisfying) to just build my own gui functions/widgets with raylib (inspired by raygui).
https://github.com/dsego/strobe-tuner/blob/main/app/gui.odin
o Tiny: around 1100 sloc of ANSI C
o Works within a fixed-sized memory region: no additional memory is allocated
o Built-in controls: window, scrollable panel, button, slider, textbox, label, checkbox, wordwrapped text
o Works with any rendering system that can draw rectangles and text
o Designed to allow the user to easily add custom controls
o Simple layout system"
https://gitlab.com/bztsrc/smgui
I don't like immediate-mode, because you must handle everything in the same thread, so mine is a state-mode GUI.
For immediate-mode and ANSI C, there's also Nuklear:
https://github.com/Immediate-Mode-UI/Nuklear
This latter has all the bells and whistles.
Like a debug UI in a game engine, or in an embedded device that doesn't even have input for a13y.
For example - in your debug UI, colorblind-friendly colors don't matter, until you hire your twelfth member of the team, who struggles to tell red and green apart.
I find it so unfortunate how many of the criticisms raised here are mooted by simply glancing at the README.
There's an interesting conversation that could be had about the needs and limitations for debug UIs, and how to balance that with minimal code. (E.G. Would feeding this library's text-and-rectangles output into an accessible renderer be enough?) But blanket rejections and reflexive judgement aren't helpful.
Dear ImGui [0] is without a doubt the most prevalent immediate mode UI library. It does not have native accessibility features, but that hasn't stopped companies such as Intel, Meta, IKEA and Google from shipping products built upon it. It's also used in a ton of games.
Calling Dear ImGui a toy project at this point would be like calling Unreal Engine a toy project.
It's a shame accessibility support is not more widespread, and furthermore it's a shame that it is so laborious to add it.
I judge software harshly that could be useful to folks with accessibility needs that don't try to address it (within bounds of their resources and capabilities, obviously lots of OSS just doesn't have the ability to deliver an accessible experience for tiny little throwaway apps). I definitely choose technologies to use based on whether they can be accessible with a little extra effort on my part. I'm not necessarily good at it, it's a complicated topic, but when I get bug reports about an accessibility issue I tend to drop everything else and try to fix it.
I guess a lot of folks consider games exclusively for folks without those accessibility needs, so maybe that's why something like Dear ImGui can live for years in thousands of projects without anyone complaining about accessibility. But, I wouldn't consider it for anything that isn't specifically about graphics and I don't think anyone else should either. (No one has to listen to me, but I think less of them.)
Immediate mode UIs are mostly for debug menus, not even gameplay/graphics. It doesn't need to be accessible to anyone except for the developer(s) choosing the library and making the game. (If the developer has different needs, obviously they can choose another library, unlike users who must live with the developer's choice.) The fourth sentence in the linked ImGUI repository explains this intention very clearly.
You can spend all this energy imagining malice and thinking less of others, but doing so does not add merit to your critique. Nor does it advance the cause of software accessibility.
You made up a guy and pretended I was yelling at them.
Literally all of them are using it as part of non-user-facing debug tools for 3D graphics:
https://github.com/ocornut/imgui/wiki/Software-using-dear-im...
Meta as part of their VR/gaming division, Google in their VR division and 3D rendering engine, Ikea in a 3D material editor, and Intel in a 3D SDK.
And again, the intended use is immediately explained on the project repo no matter what the comment you were replying to said.
But, in my defense, I did say "software that could be useful to folks with accessibility needs that don't try to address it (within bounds of their resources and capabilities, obviously lots of OSS just doesn't have the ability to deliver an accessible experience for tiny little throwaway apps)". If that aint you and that aint the software you're making, I'm not talking to you. And, sometimes accessibility isn't just for blind users.
This post is about a minimal immediate mode library made by a game dev, most suitable for debug menus.
It's unreasonable to treat it as a platform for soapboxing about "the vast majority libs" that are unrelated.
The first WAI-ARIA specification was published in 2014 [0]. HTML5 became an official W3C recommendation that same year [1]. It includes semantic elements like <nav> and <main> that have ARIA roles built in [2]. The Wikipedia page for WAI-ARIA includes the "five rules of ARIA" where the first rule is "Don’t use ARIA if you can achieve the same semantics with a native HTML element or attribute" [3].
You almost always still need some extra ARIA attributes to be fully accessible, but it's much less extra work than most other platforms and it works (mostly) the same on every operating system (including phones). You don't have to build anything yourself-- you just have to know which attributes to use. Just ask any blind people you know whether they prefer using a website or a native app.
[0] https://www.w3.org/TR/2014/REC-wai-aria-20140320/Overview.ht...
[1] https://www.w3.org/news/2014/html5-is-a-w3c-recommendation/
In the MicroUI example here, there are buttons and text labels and other kinds of controls, but no ability for an outside process to enumerate or interact with the controls. Any program will just set a single giant window with no text and no controls inside. Accessibility software can still hook text output APIs, but not if it also uses custom font rendering.
Anyway, the Windows accessibility API is just implementing a few COM objects, and COM (other than the specific ABI used for storing the vtable and function call convention) is not necessarily specific to Win32.
Really insane comment TBH
It is sad that the world is so hung up on unicode and things like accessibility that we all have to submit to the tyranny of browser layers!
It is sad that the world is hung up on enabling 2/3rds of the world population to read and write text! If only the entire world catered to America. Nobody should ever speak anything other than English, honestly.
As for linking to something written in Rust with bindings etc. - that is the opposite of tiny when you consider the dependencies, and it would not be portable to weaker or older systems.
Note that any project using Dear ImGui will presumably have read the README for it, the second paragraph of which starts:
> Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user).
You're right though I'm already thinking of scaling and hidpi as another thing I need.
Lvgl is 440kloc across 1134 files (in the src directory), while microui is 1121 lines of code in one .c and one .h file.
Microui is immediate mode, very minimal and 'bring your own renderer'. Probably most useful for adding a small debugging UI to a 3D game/app.
You plug it into your project and it can be rendered on anything that can push pixels and/or triangles to the screen. Events from windowing system go in, list of triangles comes out.
This is intended to be used with OpenGL, Vulkan, D3D and other graphics environment and used in cases where integrating a "real" GUI toolkit would be more trouble than it's worth.
Other popular libs like Dear Imgui or Egui work the same way.
question is how produce sms-message like text widget, with alligment like iphone
But the way how text rendering is delegated to the user is quite flexible, microui basically calls these three user-provided functions:
int r_get_text_height(void)
int r_get_text_width(const char* text, int len);
void r_draw_text(const char* text, mu_Vec2 pos, mu_Color color);