Blender's UI and Runtime: Much Faster Than GPUI
github.com
github.com
But the worst part is all code snippets are followed by an image which is not related to the code snippet. It's not what you get by typing the code... it's something completely different.
To the project maintainer: don’t ask people to read a terrible AI generated sales pitch novella that quantifies your AI generated port against every UI framework out there.
Here’s the obvious giveaways:
“ 4. The many ways in” “ Python, four ways”
“ tkinter: all 7,846 public names of tkinter and ttk. Nine real programs behave identically on the standard library and on BUI.”
“ Rust: the web platform, natively”
Ugh it’s excruciating. You’re better off with a readme that shows a few screenshots and installation instructions.
1 - thanks to the poster that mentioned nausea, I've been looking for the word to describe LLM based writing for a while and it's perfect.
"down to earth" and "hobby-project" does a good job. its still not perfect but better than the vanilla output. eg. https://github.com/busssard/OpenRing
This is further evidence of the need for small models doing specific things well.
Where I would say models fit in the process is establishing the general layout of documentation and iteratively refining things out. Interestingly, it’s the same for image generation too. But 9 out of 10 it creates incomplete work that needs refinement.
Go wide, then hone in, refine. There’s no such thing as getting AI to single shot creative tasks. Which is funny because everyone thought writers are on the chopping block initially, but that is unequivocally NOT the case.
Even technical tasks, agents doing it their own way yields garbage in some right. It’s just a question of how long it runs before it goes down a path of no return.
Human in the loop is the only way. And, to be honest, what’s the f*king rush anyway? We all need to slow down. Good ideas with unravel in time. :)
like, if people are gonna be turning the crank to generate prose-like text from statistical models and calling it a day, aren't "subagents" a hip new thing nowadays? there do exist models that aren't overcooked to impressively bad long-tail in the pursuit of maximum coding benchmark scores. such other models generate prose-like text that is significantly less miserable to wade through.
if you're a vibecoder who's terminally committed to the bit, for god's sake, at least tell a local gemma to draft your readme or something. an occasional outright falsehood is less damaging to usability than the experience of reading feeling like trudging through a pool filled with treacle. (mind, both are a violation of trust, and a failure to deliver proof of work, and please stop, but at least if the falsehoods are comprehensible and identifiable there's light at the end of the tunnel)
Edit: I found reading those examples in the most sanctimonious voice I could imagine seemed very plausible - maybe LLMs sound like they are up their own arse.
I remember someone once created a GitHub issue requesting I turn the README into some verbose technical thing with full API docs and a bunch of people replied saying they greatly preferred the "pitch + high-level examples" style.
but also the fact that yours is the most upvoted comment tells me there are entire swathes of people for whom that style works, and i am interested to get in people's heads about that, because it might yield some insight re: for what kind of audience these labs are optimising the style of text these models generate. so, if someone is reading this comment, and you broadly agree with the comment i am replying to, please answer these questions:
1. is english your native language?
2. what about the prose do you find appealing?
3. do you not find the structure (colossal wall of text, infodumping about largely irrelevant details) annoying/noisy?
4. does the word-to-word style and clichéd phrasing not immediately set off your llm alarm bells?
i guess people can answer if they disagree too, if they really want to
1. English is my native language.
2. The organization was to the point (eg it described what this is and who would use it up front). I can't say I found the prose "appealing" -- about the best I can say is that it was so obviously LLM writing that it implicitly told me that this is most likely a large mostly unattended porting project, which helped me set my expectations accordingly. Note that this is also why I stopped after getting a good feel for what it all is; the project would be interesting if I had a need to make something with that exact style of UI, but otherwise there wasn't going to be some shiny new idea or brilliant perspective that I could apply more widely.
3. Partly. It was a wall, but not that impenetrable a wall. There's plenty worse, and it was broken up enough for me to get through. Things were signposted well enough for me to skip a lot of what wasn't relevant to me.
4. Oh, absolutely. See above.
I'm finally growing the ability to extract value even after detecting that text is in the en-SLOP locale. Originally I couldn't detect it, then I could and couldn't tolerate it, now I'm starting to be able to treat it like broken English or caveman speak. I have to work to extract value, albeit a different type of work than those two.
It's mostly about suppressing my reactivity to the choppy phrasing and braggadocio (which are both the results of reinforcement training to elicit exactly the sort of reaction that I'm suppressing).
"Blender's user interface, as a library you can use from Python, Rust, JavaScript (React, Svelte), C, C++ and Dear ImGui."
This tells me a huge amount of what I need to know, if I'm interested in this project or not.
Compare it to another very recent example posted on hn: https://github.com/rivet-dev/rivet - You need to get some way down the page until it discloses what you might be able to do with the project. https://github.com/rivet-dev/rivet#use-cases
But by that stage, even though it isn't very far down the page, I'm already checked out.
We also have a discord server, lmk if you're planning on using BUI!
Then, the README very quickly continues with "What BUI is" and "Why BUI exists". These are all the exact things I want to know, ASAP, when I encounter a new project. The language reads perfectly fine to me.
Here is another example of a nice README: https://github.com/mpv-player/mpv
Do you know what I don't want to know first? What the startup time is, what language you wrote it in (because you think it makes your project cooler), some other random internal details about the performance of the thing, when I don't even yet know what the thing is.
You mean something like:
> turns it into a standalone UI library with a small C core
...?
Or this:
> At the heart of BUI is the kit: a small runtime written in C
......??
I personally have no issue of this, but the more I read your comments the more confused I got.
If that's an LLM-ism, then it's one that I hope spreads.
And I do appreciate the effort that goes into it, especially in the latest versions as it got much better,
But I really really really REALLY don't want that UI in anything else other than Blender.
Please don't.
If you're already using Blender to make assets, there's some benefit to stuffing Blender's UI into your game editor too.
Not in an age of AI.
I mean if you want to code all this stuff by hand, I get it. But that's a choice. And since it's a choice that means shoehorning a Blender UI into a "bargain-basement game editor" (and having a "bargain basement game editor) isnt really needed. You absolutely don't need to spend a lot of time arranging UI stuff.
Game tooling is pretty trivial now and it's not user-facing. Again, I fully understand why someone would want to do this themselves still but let's not pretend thats not a choice at this point.
Edit: the snark I’m responding to has been edited out
I have used 3Ds max, maya, lightwave, cinema4D, milkshape, wings, Houdini, unreal engine 1 - 5, Hammer, Threejs editor and probably more. The Blender UI is worse than all of the above.
Zbrush is ok.
You've given quite a list of tools with different purpose.
For 3D work I would personally rate
Modo 3D, Zbrush > Blender, Houdini > Softimage XSI > Maya > space intentionally left empty :P > 3Ds max
Blender UI looks very nice and is very customizable. I think it's "ok" in beginner discoverability (none of 3D softs is great at that really) but when you get experienced with it it's one of the best.
I really like how they managed to keep all the tools and views pretty consistent given how many things you can do in it. Whether you are working on objects, vertices, nodes, movie clips you get the same shortcuts where possible.
Maybe some of them do, but even though I disliked the UI at first, I've come to appreciate it as I've learned it. It's simply different from most other software, so that obviously causes friction. However, I think once you learn it, it's quite a good system. There's a tradeoff between optimizing for familiarity/new users, and providing an optimized experience for advanced users.
Blender does a LOT of stuff. Its not an easy product to create an UI for. But I think the problem is much bigger when coming from a different 3D package than when learning from scratch.
My teenage kids use Blender as the first 3D package they've ever learned. I was impressed with how quickly they ramped up through videos and learning from each other.
My baby duck fingers could probably pick up LightWave 3D again in an hour or two. I could never gel with Blender.
A lot of people go "Blender UI was horrible, but they redesigned the whole thing and now it is good" Having used blender in a minor role for 20 years(i think I started on 1.7), I think this was just a big psyop by the blender team. Sort of how the client goes "Change things" and you change nothing, wait a day, and tell the client "I made the changes you requested" client: "I love it"
I am not saying the blender team has not made substantial improvements to the UI over the years, but the core is still that same quick blender workflow, This is very different from the normal clunky GUI design of 3d modelers of the era and as such blender got a reputation for having a weird UI which was easily translated to blender having a bad UI. So what do you do when you have an unwarranted bad reputation? Especially now that the rest of the world has caught up and is using your flows and they are not so weird anymore. Make a dark mode and put out a big press release "we redesigned everything, it's good now" so people will try it.
> Baby duck syndrome is a cognitive bias where people automatically prefer the first system, interface, or product they learn to use, judging all later versions or alternatives by how well they match that initial experience.
That's actually extremely common in scientific (GUI) software. And in any professional setting I guess.
I don't think that qualifies. There's an important distinction to be made between an aesthetic preference versus a professional not appreciating a tool being mucked with. Anything that interferes with my workflow without immediately providing substantial benefit is something that's actively harmful. In fact even if it does hypothetically provide huge benefits I still might not want to deal with it right this second.
So if it's for an employer it's rational but if you're making the same choice for yourself it isn't? If one of those is baby duck syndrome they all are.
I absolutely detest it (TBF I haven't used it for the past ~2 years) but I also recognize that it's an incredibly difficult problem space that lacks an obviously good solution, the tool itself is inherently and irreducibly complex, it's a free project with extremely limited resources, it's been consistently improving over time, etc, etc.
It is actually a miracle that it is as good as it is considering other open source graphics programs like GIMP are horrendous to use.
Fundamentally all 3d modelers have inherent degree of complexity. The ones that give a "simple" facade with fewer options make other things harder or having to look into obscure places.
All of that are beside the point however: people will use this as a GUI library, not as a Blender's UX design.
It is not a UI paradigm that you would use for just anything, but for certain poweruser software it is one of the best paradigms I have seen, especially since they managed to get rid of 90% of the rough corners in the past decade of development.
But a good design system does the trick. Artcraft apps use this library and their Adobe clones come very close to the original apps.
Q: “Whats wrong with tkinter?!?!”
A: It sucks, that’s what!
That UI is fine to be on many more places than Blender, given that many libraries people use are way worse. Imgui for one example.
Yeah you can do that. If you have low standards and don't need control of the details.
Now as an adult, I can see why they removed it. It didn't make sense to put resources into it.
I'm really happy about the UPBGE project. It doesn't compare to the capabilities of Godot, but that's okay. It just makes me happy that someone else cared about it enough to pour time into it.
I do hate vibe coding. So I took a different approach for BUI.
Instead of asking the agent to decouple the UI, I asked it to remove all the parts which isn't a part of UI logic.
Turns out AI is pretty good at removing than generating.
That's an interesting distinction. A distinction without a difference in my opinion, but a distinction nonetheless!
Median update+build time per frame (ms), lower is better
Machine: macOS 26 VM, Apple M4 (virtual)
benchmark (ms) Dioxus Iced egui Slint GPUI
create 1k 12.91 17.57 10.66 26.99 22.32
replace 1k 14.46 14.48 7.48 17.07 17.41
update every 10th 2.12 1.94 4.17 5.55 10.65
select row 1.16 0.37 3.50 6.62 10.68
swap rows 1.45 0.42 3.53 4.10 10.26
remove row 1.32 0.39 3.27 4.46 11.95
create 10k 124.97 152.52 58.97 136.07 164.58
append 1k to 10k 28.12 157.67 33.01 69.93 117.70
clear 1k 3.00 0.86 0.07 4.60 0.04
scroll frame 0.28 0.10 0.55 4.23 3.79
These are CPU-only times for the state management / style / layout / etc, but don't include rasterization (additional work in the benchmark harness required to measure GPU time sensibly), probably aren't fully apples-to-apples, and could probably do with testing some more complex layouts.
The main thing GPUI has going for it is mind share and that's a great thing to have. The mind share is unfortunately highly fragmented though as the original authors are not interested in selling a GUI library. Hopefully the community efforts will come together to produce a more polished and general library. A well used library is better than a better designed one maintained by a single person.
It’d be like naming my http library HTTP.
And it’s why Dear IMGUI isn’t just named “IMGUI”.
When they tried to jump on newer trends they made them all monochrome, and they don't have distinctive sillouettes so it's just completely inscrutable. That Inkscape screenshot is horrible. I count 129 icons.
And yet they still devote so much space to their bizarre colour palette, which is huge but still manages to omit most of the gamut? It's the kind of design that really only comes from decades of OSS development.
[0]: https://gradia.alexandervanhee.be/ [1]: https://www.pinta-project.com/ [2]: https://krita.org/en/
I’d be interested to know what you think about it
I tried it out, and it's a pretty good clone. It serves my muscle memory well, with a few hiccups like drag-and-drop image onto the window doesn't work exactly the same, the save menu is a bit different. But there are also some pretty good improvements, like the addition of text layers (text got rasterized immediately after loosing focus in paint.NET which made it HORRIBLE to work with. This change is super welcome). There are also a bunch of new "plus" menu items that it seemingly gets from PhotoCraft? Not sure if that's because I have PhotoCraft installed, or if it comes with those features bundled. I'm not sure how good this is, because Paint.NET menus were already quite bloated and confusing to navigate, so this makes them even more cluttered with for example "Hue / Saturation" next to "Hue / Saturation +". The UI windows can't be dragged out of the paint.rs window like they could in Paint.NET. I think this is also faster than Paint.NET was.
I like this, it's quite good. I would like a more modern UI though, ideally using native GTK elements. Though that raises and interesting question of how much should a re-implementation veer away from the original. I think I'll keep this as a backup if I get fed up with PhotoCraft.
Swapping it for UI that's as battle tested as Blender might improve things.
GPUI and Makepad are the two Rust UI frameworks that seem the most interesting for what I'm looking for in a UI framework (hybrid immediate/retained mode, self-drawn widgets, open source).
Especially since v2 and v3 have vastly different consequences.
GPL makes sense for applications like Blender. For a general purpose library, it's a dealbreaker.
It "cannot be considered" only for proprietary apps.
But that wouldn't work for a straight derivative of a GPL project.
“ No accessibility support. BUI draws its own widgets and does not talk to the platform's accessibility APIs (UI Automation on Windows, AT-SPI on Linux, NSAccessibility on macOS), so screen readers can't see them. Don't use it for software that has to be accessible. Accessibility is planned. “
It's time to do it! Also we have a discord, if you end up reviving it, do share it over here:
> The drawing code is a C port of Blender's own widget code
How can we guarantee BUI is still performant?
Also speaking of FastAPI, have you checked out FastRAPI?
I hope someone else uses this for a new Linux distro.
I'm an EGUI fanboy, but am looking to truly compare it to other things, especially non-immediate mode. I have no gripes with EGUI, other than it seems to create an application size floor, and I suspect memory use could be better. It has never blocked me, including for complex applications with GPU rendering etc.
Blender is peak OSS. I'm in! Will give this a shot for my next limited-scope application. I'm also experimenting with GPUUI.
I will try Slint if I ever do embedded with a full GUI.
I will poke at this, because I saw the same sentiment in a HN thread yesterday: >" You write Rust or React and want a native desktop UI without shipping a browser." You don't need to ship a browser to do GUIs in rust. Some people do, and justify it through comparisons to Electron (Tauri) - I suspect this is a pushback against that?
Another thing I will poke at from comments: If you're going to dismiss this as a non-native UI and therefor inferior: Post specifically what features your OS-native toolkit or OS conventions have that won't work here. (Is it hotkeys, color scheme, a Je-ne-sais quoi? What OS specifically? My pet theory is these are all MacOS users, but I'm not sure)
I'm really liking https://github.com/anomalyco/rune so far. Designs come out much nicer looking
Was recently trying to learn a desktop toolkit again and was disappointed that the docs of pygtk and rust/iced end around page three. Many projects, little follow up. Probably should pick a toolkit from the 90s instead.
This seems different. Also, tabs that look like tabs! Love it.
Check out the docs here: https://bui.preetham.top/
> The repository is built entirely using LLMs, with no human-written code. The drawing and interaction code is ported from Blender's sources, and the behavior is checked by tests: C, Python, Rust and JavaScript suites, the tkinter side-by-side programs and the GPU parity test.
...wasn't it?
But, if I did not invest last two years into my own toolkit, I'd definitively consider.
I think I will keep going with my own efforts, but this looks nice!
We also have a kotlin binding support coming soon, btw!
>The repository is built entirely using LLMs, with no human-written code. ...
I’ve not once thought “Man, those widgets are slow!”
Do Maya and others have better UIs? Honestly, I find them more repulsive than Blender's
Just because you can...
Direct3D is at version 12 on Windows[1].
What tech on macOS? OpenGL?
I just tried few very standard operations that every Blender user knows:
1) Drag vertically across multiple number inputs to enter multiedit mode - failed (even though main page advertises this: "Drag down across X, Y and Z to edit all three at once")
2) Hover on field, press Ctrl+C, hover on another field - press Ctrl+V - failed
3) Press shift while dragging - it glitched
4) Scale UI - failed
5) Collapse collapsible block - failed
6) Right click - reset to default - failed
7) Jump to next field with Tab (while editing) - failed
8) Automatic alt accelerators - failed
9) Tooltips - N/A
10) AI slop: funny cursors, focus outline
So basically it is more like styled imgui (less polished than Blender), rather than Blender's UI.
I'm not saying that it is impossible to do a honest implementation, but one needs to kick agent much more to prevent cheating, and actually know how Blender UI works.
It works perfectly on my machine, and another friend's machine. Just to be sure, which demo did you try? the website or python or rust?
Probably it works in other implementations (I did not try); in web it produces <input type="text"> and agent likely gave up trying to simulate such details there.
Let me update the web samples. Thank you!
If you want share a demo, maybe canvas-based would work better (e. g. https://www.egui.rs/)?
Why are the progress bars gradients? Blender doesn't use a single foreground gradient. Why is there a shadow on the thick status bars in the middle? Why are headings different colors? Why are there badges? The fuck is this, tailwind? The icon on the dropdown menu top right isn't centered properly. Right to jail, right away
Is it retained mode UI?
Is it just me, or is this late stage token-utopia derangement? It took me quite a few tries before I could put Blender to any actual use because of how ... unusual ... the UI was.
Who is "we," and what's the long term plan?
It's a shiny presentation, but I don't see anything on offer more than a solo dev who pointed AI at the Blender codebase. I could do that myself, and many of the reasons I don't do that apply directly to why I'd never use this project.
I think the GitHub readme and the docs site are dishonestly presenting the state of the project.
I don't think we can use LGPL since we were derived from Blender's Source code, which is GPL.
Question, is there an effort to have blender use the library? Avoiding drift would be really important.
But what is actually in that project? All of those things? Just a C runtime? Why not talk about what the barebones C runtime gives you first (memory, runtime), then add whatever layer on top? Or is it all-in-one always?
A quarter-century ago, yes. If they haven't migrated to native widgets in 25 years, that might be an indicator of something
But the premise is silly: if Linux has two native toolkits, how is this a sensible recommendation?? Hint: it isn’t, because GTK/Qt are not the native, but rather simply the most used.
Also, go to Mac, and SwiftUI still doesn’t support all that AppKit used to, leaving an incentive for developers to deviate from the platform’s recommendation.
And back to Windows, WinUI still doesn’t fully replace Win32 or Windows Forms, so same conclusion applies.
I’m going to hazard the claim that in probably most people’s conception of the term, GTK is native in GNOME, Cinnamon, Xfce, etc. and Qt is native in KDE, LXQt and Sailfish OS.