>I sincerely hope no one looks at the screenshot on that page and thinks "this is something that works well". This UI screams "I've been made that way because that was the easiest way in the tool I'm built with"

That's where you'd be wrong. Profilers traditionally have looked like this regardless of the tool/GUI lib/GUI paradigm they'd been made with.

It's the domain need (to show lots of information, graphs, timelines, stack trees, etc, to compare) that asks for this...

How would a profiling tool UI need to look differently in your opinion?

And why do you think the UI looks that way because of restrictions of the UI framework?

I'm quite sure if the UI would have been written with (for instance) Qt or React, it would look exactly the same, because the UI requirements would be the same (minus the different default style). The question is whether this could have been achieved with less, or "cleaner" code (which I doubt).

Probably a decent chunk of the perceptual issue you're seeing comes from their choice of font rendering library, which is noticeably "the IMGUI font rendering library", and looks amateurish. This is stb_truetype, which is a very primitive library, but is easy to install and incorporate. The other library is freetype+harfbuzz, which produces higher quality output, faster, and with lower memory. The cost of freetype is that installation is absurdly difficult, the maintainer is offensive, and the code is ancient, unreadable, and architecturally a disaster.

I don't think the chosen GUI library causes the other UI issues you perceive. The author probably hasn't put much time into learning visual design, and thus fell into whatever the UI library supported. But to produce a better one, the author would have had to do a lot more learning and thinking, which is independent of the library choice.

seems pretty information dense to me. tufte would approve. but surely he's no match.