Live data from Hacker News

MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

github.com

81–90 of 91 posts

Re: MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

#81

Earlier quoted context omitted.

Why is the WASM demo so fuzzy? I am on Windows/Firefox. https://imgur.com/uy78t52

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 resoluti…

Dear ImGui looks a lot better.

Re: MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

#82
post #57

Earlier quoted context omitted.

The problem is always: you don't know beforehand what bells and whistles you will need. That's why Qt is probably the only safe bet (or Web/Electron if you don't mind the slower performance).

I know exactly what I need. I just built a task manager in C with GTK+. It uses the theming built into GTK to allow users to change themes while the program is running but it's too memory heavy for my taste. I also have a background in web dev and understand how to build for accessibility. Currently the memory allocated for every single process on my computer is https://github.com/hparadiz/evemon You're right though…

[deleted]

Re: MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

#83
post #71

Earlier quoted context omitted.

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.

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

Re: MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

#85

Earlier quoted context omitted.

> 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.) Imme…

Literally none of the examples of large companies using it in the comment I replied to are game companies or using it for game debug menus. You made up a guy and pretended I was yelling at them.

> Literally none of the examples of large companies using it in the comment I replied to are game companies or using it for game debug menus.

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.

Re: MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

#87
post #83
post #71

Earlier quoted context omitted.

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.

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…

> - 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.

Re: MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

#88

This has been my goto for personal toy projects for a while now. Trivial to slot in to basically anything that can display text and takes mouse input. 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 is…

Genuine question; abandonware or complete? Something of this size serves as a nice substrate or starting-point regardless.

Exactly. Software can be _done_.

And that's okay(tm).

Re: MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

#89
post #5

The first thing I look for in any UI library is accessibility support. Makes it trivial to filter out toy projects.

Everything is an engineering decision. Leaving out something doesn't mean it's a "toy". So, I don't really get your criticism here.

Re: MicroUI – A tiny, portable, immediate-mode UI library written in ANSI C

#90

Earlier quoted context omitted.

Literally none of the examples of large companies using it in the comment I replied to are game companies or using it for game debug menus. You made up a guy and pretended I was yelling at them.

> Literally none of the examples of large companies using it in the comment I replied to are game companies or using it for game debug menus. 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…

I stand corrected.

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.

Post reply on HN