Hacker News Reader

Hacker News

Comment by flohofwoe | Hacker News Reader

Full thread

flohofwoe

I wrote a little demo to run microui on top of the sokol headers here, it's really interesting in how minimal it is.

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

View on HN

I made my own WASM demo @ https://microui-wasm.vercel.app/ and it's only 14.6 kB compressed!

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

Your demo seems to constantly consume 100% CPU at all times.

Ooh interesting. What is your machine and browser? On chrome with my m1 macbook it takes less than 1ms to compute and render each frame, but I am noticing some things I can optimize from the performance flame graph! I will say, I find chrome to be way more efficient for ctx2d things than firefox or safari.

Firefox on Linux.

Chrome on Linux suffers from this too. The issues are standard for all naive immediate GUI libs:

- 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

> - constant repainting (while literally nothing changes) -> constant CPU load

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.

Why is the WASM demo so fuzzy? I am on Windows/Firefox.

https://imgur.com/uy78t52

Looks like the rendering functions used in the demo are doing antialiasing without font hinting?

TL;DR: it can be all sorts of things, from 'half-pixel' positioning problems, to upscaling issues, to poor source data. I didn't put too much effort into getting the text rendering look good (and text rendering is hard).

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

Dear ImGui looks a lot better.

pretty nifty but im trying to figure out what the use case for this is when its aimed at hobbyists ?

I use pygtk and dont have to fiddle with lower level stuff

Minimal debugging/controller overlays for games would be the most obvious use case (e.g. similar to dat.gui for web).

pygtk requires GTK, this library works with any rendering library that can draw rectangles and text

I asked Claude to write one from scratch. A few minutes later it was done with exactly the features I needed. I started with some existing one, but when it couldn't handle multiple pointers (2 hands in VR/AR each with a pointer) without major mods I end up asking Claude if it could replace it with a custom one.

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.

Reply on news.ycombinator.com