PanGui – A cross-platform UI library with a razor sharp focus on performance | Hacker News Reader

PanGui – A cross-platform UI library with a razor sharp focus on performance

pangui.io

70 pointsPaulHoule35 comments

> Most modern applications - composed of barely more than a few images, buttons and lines of text - sit uneasily upon towering tech-stacks comprising millions of lines of code. The industry is plagued by overcomplicated, slow and buggy software that is painful both to use and develop.

Well, they got this right.

Good GUIs are deceptively easy. Lines of text: font rendering is pretty difficult to begin with. But it gets harder when you want to match native platform look, handle different display sub pixel layouts or are dealing with a script that doesn’t fit into a font atlas. On top of that you get text layout which requires careful trade offs between performance and quality as well as a huge number of edge cases you need to handle. A couple lines of text is easy if it’s fixed layout, monospaced, ascii, but unless you are making dev tools that’s the exception not the norm. Images: there is a lot of complexity hidden in your image decoder, but even if you disregard that, you have to deal with proper caching and resizing to get good performance to manage vram constraints, handle different screen densities and smooth zooming. On top of that you might need to open the can of worms needed for hdr. Buttons: if you need buttons you probably also need a text input. Implementing text input in a way consistent with platform expectations, properly supporting IME and accessibility. There are a bunch of these more lightweight UI frameworks and they are great if you are building a terminal or a text editor. But for desktop or mobile software used by regular people you really need those millions of lines of code.

    > with a razor sharp focus on performance

Is it interesting that they chose this phrase. How does it compare to Qt performance on their supported platforms? I cannot believe they will be faster than Qt in 2025. To be clear, I don't think a general UI framework needs to paint GUIs any faster than 60 frames per second. If you need faster, then use a specialist graphics framework, like SDL. That said, the Qt commercial license is very expensive, so maybe they can compete with lower prices (and somewhat lower quality).

SDL is only a graphics framework in that it gives you a window, input events, and either a putpixel/blit functions or OpenGL. It does not have graphics primitives, like what used to be called "glut" in OpenGL itself (but supporting normal platforms, glut supported SGI Irix, BeOS and OS/2, but felt that Win32 was too niche to care about, and they never voluntarily cared about linux). Like even now it seems to think that this whole IOS and Android kerfuffle will blow over soon, not worth any effort.

SDL is like a (much better) glut that has sane platform support (and audio).

PanGUI gives you graphics primitives, nicely done and executed and seems to have a much saner selection of platforms (and also gives you audio), as well as supporting a great many languages to code in.

    > SDL is only a graphics framework in that it gives you a window, input events, and either a putpixel/blit functions or OpenGL.

Do you think that Qt cannot do that?

I didn't talk about Qt at all. But yes, I imagine Qt can easily do that, and you probably can get it going with LGPL Qt, but it's not going to be easy to avoid the commercial license. I hope PanGui can do better in this regard.

Seems artificially constrained. The vast majority of devices today are >60fps.

Uh, No?

I agree that most >$600 phones are >60hz, as well as a lot of mid-to-high-end laptops (>$800), but that's not even remotely close to the vast majority of devices.

I also agree that nobody should limit it to 60hz though, but the global percentage of people using >60 Hz is likely single digit

Fair, I should have said greater than or equal to 60fps. CRTs could handle at least 60fps, and I'll be impressed if you can find a <60fps device for sale in the past decade.

The "vast majority" of devices that Qt targets today are <= 60fps. Somewhat unrelated: Are there any desktop apps that needs >60fps? I see no business value.

Do you have a source for that? I've been struggling to find any hard data.

What apps benefit? Anything motion heavy.

https://www.testufo.com/

Need might be a strong word, but that's my point with "artificially constrained." Reminds me of the potentially apocryphal Bill Gates quote:

> 640K ought to be enough for anybody

I wonder if it will be accessible or not? Uis thst are immediate mode usually aren't, unfortunately.

Did something new happen? Can you actually use it now somehow?

This was announced (and discussed with no interest a year ago, previously on https://news.ycombinator.com/item?id=39997562 and /r/unity3d)

What language is this UI library targetting? I could not find this on the main page.

it is written in C# though they seem to have plans to create libraries for a variety of platforms. that said, there is no code or interactive demos available

These examples are in C#

https://pangui.io/#hello-world

but they claim it will be "language agnostic" and C++ is the next target, but maybe that just adds to the vagueness.

If it stays written in C#, I'd imagine it will be NativeAOT-based with C exports on top of which the bindings are based for other languages. Or not, I'm watching PanGui for some time and hope it releases but no news so far.

C, C++, C#, and probably Rust. There’s a section about that. There’s a link to the FAQ I. That section.

c#,c++,c,Rust,...

see the Language-agnostic section

This is the biggest red flag, they want to support a bunch of different platforms at once over just focusing on one or two

“All these examples are written in C#, and are created using our Win32 platform integration. As such, they are using an API that is idiomatic to C# and made to feel nice to use in specifically C#.

Keep in mind that PanGui is designed to be language-agnostic and will be transpiled to many languages, with C++ being the next target language. Where necessary, the user-facing API will always change to feel natural to use in the target language.”

Unsure if the whole thing transpiles or it’s C bindings with a transpiled shim. Either way, not having the source to inspect makes the package a tough sell to most here, I’d imagine.

Graphics (includes layout, colors, fonts, etc.) constraints and the "just data" approach is what I had built into LayJS [1] (still WIP). This feels like the best approach for UI, where data and graphics can and should be seen in the same level of constraints and manipulation.

[1] https://github.com/endfront/LayJS

Cool! Reading through the page, there seems to be people behind this who know what they're doing.

”Many core features like the retained-mode layer and input controls are still in their early stages and are not presented here.”

It's funny that they show https://xkcd.com/2347/ to illustrate the "problem" but ironically they're going to end up with https://xkcd.com/927/

So Unity’s own ui tools should suffice? Do they?

I think a lot of things end up at xkcd.com/927/

Sometimes its maybe about reinventing the wheel , sometimes people create micro optimization in their standards.

It's got to the point where I've memorized the number from it being cited so often on HN

A UI library does not have the issue of standards; you can use it no matter what everyone else is using.

> Look, we're going to level with you. We really don't know. We have two overriding priorities:

> First, we want to put PanGui into the hands of as many people as possible and make it as accessible as possible. Second, we would prefer not to starve to death.

> The extreme version of the first priority is making PanGui fully free and open source for anyone and everyone. The extreme version of the second priority is creating some pricing scheme where people have to pay us exorbitant fees just to glance briefly at an impressionist painting of the source code.

> Clearly, neither will work out, so our goal is to strike some balance between these two extremes, preferably getting as close to the first one as possible. If you have any opinions or ideas, we would love to hear them.

> Please tell us what to do > As of this moment, we think PanGui is very likely to be some sort of open source, and hopefully the vast majority of people using it will never have to pay a dime. If we can make that work, we will.

From their pricing FAQ - I appreciate their honesty and humor.

I recommend that they use open source + GPL. Then, offer commercial licenses that are not bound by GPL and offer support.

A proprietary UI solution with no public documentation or pricing? Not sure how this bubbled up to the HN homepage.

On the FAQ, they point out that they don't know exactly what the licensing and pricing model will be, but that they intend to make it open source but also have a business model that supports development:

Look, we're going to level with you. We really don't know. We have two overriding priorities:

First, we want to put PanGui into the hands of as many people as possible and make it as accessible as possible. Second, we would prefer not to starve to death.

The extreme version of the first priority is making PanGui fully free and open source for anyone and everyone. The extreme version of the second priority is creating some pricing scheme where people have to pay us exorbitant fees just to glance briefly at an impressionist painting of the source code.

Clearly, neither will work out, so our goal is to strike some balance between these two extremes, preferably getting as close to the first one as possible. If you have any opinions or ideas, we would love to hear them.

Please tell us what to do As of this moment, we think PanGui is very likely to be some sort of open source, and hopefully the vast majority of people using it will never have to pay a dime. If we can make that work, we will.

I guess, because the problem they are addressing is acute.

Ha yes because famously programmers like to build interfaces by using rectangles in C++/C/Rust. There is a reason JSX/HTML won and I strongly believed any new native lib needs to emulate that DX to gain any meaningful traction. Something like dioxus in Rust is going in the right direction.

Reply on news.ycombinator.com