In case you haven't been paying any attention, Matthew doesn't do much with allegro.cc anymore. You'll be lucky if he even sees this.

everything on allegro.cc is out of date, the binaries, the docs, the depot submissions, everything

While I don't feel a need to knock imgui, I always had low fps, and high cpu when I tried their demo programs.

and, there are a lot of other guis floating out there too, mine included

Given it was an older laptop, that could have been the problem. But I was getting literally 5 fps and max cpu.

In my opinion the whole idea of an immediate mode gui is ridiculous. You spend every frame over and over recreating the same data structure, needlessly wasting cpu.

A better measure of a GUI is how customizable it is, whether you can skin it, whether you can configure it easily, etc...

Because under the hood, they're all the same basic widgets, just written with a different style in mind.

Also, imgui is C++. Allegro could have a plugin/addon but you could not integrate it into Allegro directly which is C only.

mmmmm GUI Thread!

For one, make sure you're actually measuring something you care about.

Benchmarks don't automatically mean anything. This is not a personal opinion.

Do you care about idle %, or do you care about performance when you're actually drawing something?

Measure a real case that is similar to what you'd use in a real product, with identical environments (no extra apps running).

2% and 3% on modern computers is within the margin of error with literally anything. It could be CPU scheduling. It could be another program messing with the cache. It could be differently coded example programs.

The book (of many editions printed) "Computer Organization and Architecture" by the famous William Stallings, goes directly in the first chapters "What is a benchmark?" and opened my mind on it. I've seen other competition experts on blogs/articles that have said the phrase, "Good benchmarks are hard to write." You may be able to find Stallings book for free in PDF form online. I've purchased multiple older editions to compare them for $3 or so each.

So while it's entirely possible one is "faster" than the other. You have to first qualify, what does "faster" mean? CPU usage? Draw rate? Number of simultaneous objects?

Even the tools you use to measure can be faulty! A program could "spike" usage faster than a tool reports and it only reports the smaller average. And much worse!

And further, you also have to ask whether performance (of 10/20/30%) even matters. At the end of the day, can you easily reason about and debug a program written with your chosen API? If one is 30% faster, but looks ugly-as-hell and is prone to breaking on many users machines, is it better? Maybe.

First of all, Agui's calculators demo uses 9 patch images and fairly big, suboptimal textures. It's a demo. But the api is designed so you can override the paint() calls and do it however you want.

I would not be concerned with 2 vs 3% cpu usage. These libraries are made to be incorporated in games running 60 fps. It's not made to render on changes.

But since Agui is event based you could technically only redraw the screen when any event occurs.

I believe use the tool that will let you be most productive. On a modern cpu, immediate vs stateful gui is negligible.

Cache misses cost wayyyyyyyy more.

If you need something to really only redraw when needed check out libraries like QT which are designed to work with a message pump.

Never choose a library based on the fact that one unoptimized demo performs marginally better than another.

Here is one of my most popular SO questions: https://stackoverflow.com/questions/2217524/how-are-3d-games-so-efficient

Oh hey, one more think I remembered but forgot to add to my post!

When you're benchmarking lower/idle CPU/GPU state watch your clockrates!!!!!!! This is an absolute requirement.

Any time you run something that yields back to the time scheduler instead of running wide-open as fast as it can, may not do enough actual work to make the CPU engage higher clock rates. You may be using as little CPU as a "background service" from the perspective of a particular CPU core, and it'll just stay in low (or lower) power mode. Under-rating voltage and/or frequency.

You absolutely MUST disable all power scaling features of your CPU if you're going to measure idle / low CPU usage with any accuracy.

And even if you're doing wide-open, you may engage "turbo mode" which shuts off cores and overclocks the remaining cores. The problem there is, you may think you're running as-fast-as-possible but then you add some more threads to use more CPU cores and all the cores suddenly get slower because they can't use turbo mode anymore!