News for hackers. Stuff that matters.
Re:MicroUI – A tiny, portable, immediate-mode UI library wri... by Narishma on Wednesday June 17, 2026 @08:31PM (#48578953)
Your demo seems to constantly consume 100% CPU at all times.
Re:MicroUI – A tiny, portable, immediate-mode UI library wri... by onsclom on Wednesday June 17, 2026 @08:42PM (#48579057)
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.
Re:MicroUI – A tiny, portable, immediate-mode UI library wri... by Narishma on Wednesday June 17, 2026 @11:48PM (#48580577)
Firefox on Linux.
Re:MicroUI – A tiny, portable, immediate-mode UI library wri... by Lockal on Thursday June 18, 2026 @06:38AM (#48583418)
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 wri... by flohofwoe on Thursday June 18, 2026 @08:29AM (#48584331)
> - 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.