Blender UI Runtime Performance Benchmarks: Why It's Several Times Faster Than GPUI

A Performance Discussion Sparked by Benchmarks

Recently, a project called BUI on GitHub sparked widespread discussion on Hacker News, with the post title bluntly stating "Blender's UI and runtime: much faster than GPUI." The post received 383 points and 154 comments, indicating that many developers are very interested in GUI framework performance comparisons.

The goal of the BUI project is not to reimplement Blender, but to validate a hypothesis: whether Blender's self-developed UI and runtime architecture is truly superior in performance to some emerging Rust GUI frameworks. The author chose GPUI as the comparison target because it is the framework behind the Zed editor, uses GPU-accelerated rendering, and is often regarded as a representative of modern high-performance GUIs.

What makes this comparison interesting is that Blender's interface doesn't look "modern"—it doesn't use web technologies, nor does it use declarative UI. Instead, it sticks to a very old immediate mode plus custom drawing approach. But it is precisely this design that demonstrates competitiveness under high-load scenarios.

Blender's UI Architecture: Efficiency Advantages from Simplicity and Directness

To understand why Blender might be faster, we first need to look at its UI architecture. Blender's interface is entirely self-drawn, relying neither on native system controls nor on a browser engine. Every button, slider, and panel is drawn directly at runtime, with layout calculation and event handling completed in a compact loop.

The advantage of this approach is predictable overhead. There is no cross-process communication, no DOM tree, no complex style parsing, and the work done by the UI thread per frame is relatively fixed. The author of the BUI project demonstrates the comparison approach in the repository: under the same rendering load, Blender's UI frame time is significantly lower than GPUI's implementation.

Of course, this does not mean Blender's architecture is superior in all scenarios. Its costs are lower development efficiency, limited customizability, and the need to manually manage state for many interaction logic paths. But for tool-type software pursuing extreme performance, this trade-off is reasonable.

Immediate mode GUI is an interface programming paradigm opposed to the mainstream "retained mode." In retained mode, the framework maintains a persistent widget tree, performing diffing and updates when state changes; while immediate mode re-executes the entire interface description code every frame, directly generating drawing commands without retaining widget objects. Its advantages lie in the unification of state and drawing logic, the absence of tree traversal and dirty-flag management overhead, and low frame time variance; the cost is that all UI code is repeatedly executed every frame, and it is difficult to achieve fine-grained partial redraws, accessibility support, and complex text input. Dear ImGui is a representative implementation of this paradigm, and Blender's self-developed interface system is conceptually similar.

Custom-drawn UI means the application does not rely on operating system native controls (such as Win32 controls on Windows or AppKit controls on macOS), but instead uses graphics APIs (OpenGL, Vulkan, Metal, etc.) to render elements such as buttons and sliders directly as textures or geometry. The biggest benefits of this approach are consistent cross-platform appearance, fully controllable rendering paths, and the ability to share the same GPU pipeline with the 3D viewport; the drawback is the need to implement infrastructure such as text layout, input methods, scrolling, focus, and accessibility yourself, resulting in high development costs. Blender relies on custom drawing to unify UI and 3D rendering within a single event loop, avoiding extra overhead from cross-process or cross-engine boundaries.

GPUI's Positioning and the Fairness of the Comparison

GPUI is a Rust GUI framework developed by the Zed team, featuring GPU acceleration, a declarative API, and high concurrency. Its design goal is not to replicate Blender's interface, but to provide a smooth interactive experience for a modern code editor. Comparing it directly with Blender's UI runtime requires careful consideration.

From the Hacker News comments, there is clear divergence in the community. Some developers believe this comparison reveals "the natural performance advantage of simple architectures," and that the abstraction costs brought by declarative UI and virtual DOM are real. Others point out that GPUI's complexity buys better development experience and maintainability, and that comparing frame times alone cannot show who is "better."

The BUI project itself acknowledges that this comparison is more of an exploratory experiment than a rigorous academic benchmark. It offers a perspective: as UI frameworks grow increasingly complex, can returning to a simple custom-drawn model yield substantial performance gains?

Declarative UI is a programming model that describes "what the interface should look like" rather than "how to build the interface step by step." Developers declare the mapping between state and interface, and the framework is responsible for computing the minimal update set when state changes. It greatly improves maintainability and development efficiency, but usually requires introducing a virtual DOM or similar diffing mechanism, incurring extra allocation, comparison, and dynamic dispatch costs on hot paths. GPU-accelerated rendering means delegating interface drawing work to the GPU rather than CPU rasterization, which can significantly improve throughput for large-area redraws and animations, but also introduces new sources of overhead such as texture uploads, batch merging, and synchronization waits. Understanding these two points makes it clear why a single metric like "frame time" cannot fully measure the pros and cons of the two architectures—they optimize for different goals in the first place.

Implications for GUI Framework Selection

The value of this discussion is not in ranking Blender or GPUI, but in reminding developers: performance is not free. Every layer of abstraction, every cross-boundary call, and every dynamic dispatch accumulates cost on hot paths. Blender's UI is fast largely because it embodies "doing less" throughout its architecture.

For desktop applications that need to handle a large number of UI elements and frequent redraws, Blender-style immediate mode remains an option worth considering. For projects that require rapid iteration and prioritize development efficiency, the abstraction costs of modern frameworks like GPUI are acceptable. The key to selection lies in clearly identifying where your bottlenecks are.

If you are interested in the specific implementation, you can look at the code and comparison data in the BUI repository. The Hacker News comment section also contains experience sharing from many frontline developers and is worth reading.

This article is based on discussions on Hacker News and public information from the BUI project. Performance conclusions are subject to the original project's data.