I love these kinds of UI frameworks except for one thing -- the text is always so poorly rendered. Not sure if it's just poor fonts or lack of good antialiasing, but compared to how a browser or native windowing system renders text, immediate mode GUIs are practically unbearable and make me want to close them after short usage. Maybe because I use a high-DPI screen (Macbook Air), not sure, but it feels like taking a step in the wrong direction for user comfort.

I must mention that the WASM demos all render to a half resolution framebuffer when running on a high-dpi display, and the resulting aliasing and upscaling may introduce all sorts of artefacts (even as late as in the browser and window system).

I've configured the canvas upscaling to use point filtering because that looks nicer for Dear ImGui's and Nuklear's default pixel fonts (otherwise the text look slightly blurry after the upscaling), but the point filtering doesn't look exactly great for microui's default font.

Using a proper TTF font rendered in native resolution on a HighDPI display will look a lot better. But proper 'non-native' text rendering is a surprisingly tricky thing to do right.

The default fonts are just plain awful. It's trivial to drop in a better font and make it indistinguishable from native.

Possibly a licensing issue as to why they don't include better ones by default as you have to bake it in? or they want to make the binary as tiny as possible by not using a bigger font file?

Font is one thing.

The hard part is text layout which is a very very complicated affair, especially if you want to support different languages and/or writing systems.

Your comment reminded me of "Text Rendering Hates You" (https://faultlore.com/blah/text-hates-you/ and https://news.ycombinator.com/item?id=30330144 )

Yeah this. Once you get to something more than plain English, it means pulling in HarfBuzz

If you want visually pleasing results, even English needs layout processes like kerning.

:-/ must have mentioned that by 'plain' I meant monospace, С64-like

This one is 1100 lines of code, nice for embedded project.

A nice font renderer is orders of magnitude more code, e.g., harfbuzz 25,000 lines of code with or FreeType with 245,000 lines of code. Many projects do not want that kind of bloat.

I'd guess some of these little ones allows using your own bmp font, so render a font you like, and use the rendered glyphs.

>Many projects do not want that kind of bloat.

It isn't bloat if it's desired functionality. Not every project is optimized to run in an embedded environment, nor does it need to be.

Adding 250,000 lines of code to render fonts to an 1100 line functional gui library is bloat no matter how you slice it. If someone want that renderer, it's not that hard to wire it in.

And if you in particular want it, fork them and merge them.

Meh. A small C library is easier to extend than a sprawling C++ library, and it's perfectly valid to want a minimal gui that can actually import fonts. Even just building a font atlas on top of that would be useful in a lot of projects.

Your demos are really cool!

https://floooh.github.io/sokol-html5/

Interestingly the imgui and nuclear both work on mobile while the microui demo doesn't appear to handle any input. Imgui works surprisingly well (although everything is a bit small for touch).

Impressive. This is suckless-grade minimalism.