GPU-Accelerated UI: What It Is and How BUI Compares to GPUI

⏱️ Reading time: 12 min

A developer identified as ppmpreetham pulled Blender’s entire graphical interface out of its original source code and turned it into a standalone library for Rust, Python, JavaScript, C, and C++. The project is called BUI, and its own repository claims it performs twice as fast as GPUI, the interface engine used by the Zed editor.

📑 En este artículo

1. TL;DR
2. What Is GPU-Accelerated UI?
3. Why It Matters
4. How It Works
   1. The C Core
   2. The Bindings
   3. Damage-Based Rendering
5. Practical Examples
6. Getting Started
7. Real Use Cases
8. Comparison with Alternatives
9. Common Mistakes and Best Practices
10. Going Deeper
11. Frequently Asked Questions
    1. Does BUI need Blender installed to work?
    2. What does GPU-accelerated UI mean in practice?
    3. Does BUI replace Electron?
    4. What languages does BUI’s native UI toolkit support?
    5. How is BUI different from GPUI?
12. References

BUI belongs to a category that is growing fast in desktop software development: GPU-accelerated UI, frameworks that draw every button, panel, and slider directly on the graphics card instead of delegating that work to a browser engine or the operating system’s native widgets.

TL;DR

• BUI extracts Blender’s widget code and exposes it as a library in Rust, Python, JavaScript, C, and C++.
• A core written in C (the kit) draws the widgets following the same code used by interface_widgets.cc in Blender.
• Tkinter apps run on BUI unchanged, according to the project’s own repository documentation.
• Dear ImGui adopts Blender’s visual theme with a single compile flag, without touching the app’s logic.
• GPU-accelerated UI avoids loading a full browser engine just to draw panels and buttons.

What Is GPU-Accelerated UI?

GPU-accelerated UI is the family of graphical interface frameworks that delegate the layout, drawing, and composition of every widget to the graphics card instead of a browser engine or the system’s native widgets, which reduces memory use and speeds up redrawing.

In practice, this means the app doesn’t open an operating system window and ask Windows, macOS, or GTK to draw a button. The framework maintains its own widget tree, calculates its geometry, and sends triangles and textures directly to the GPU, the same way a video game would.

GPUI, the framework used by the Zed editor, was one of the first to popularize this approach outside of video games: it renders the entire text editor as a GPU scene, not as HTML text. BUI follows a similar philosophy, but instead of designing an engine from scratch, it reuses the one Blender has already polished over two decades.

Why It Matters

The problem a native UI toolkit like this solves is old: building a graphical interface that looks good on Windows, macOS, and Linux always forced a choice between two bad options. Either you used each system’s native widgets, with a consistent look but three separate codebases, or you brought in Electron and dragged along an entire browser.

Electron packages Chromium and Node.js inside every application, which explains why apps like Slack or VS Code weigh hundreds of megabytes and consume several hundred MB of RAM just to show a window with text and buttons. That cost isn’t a minor detail when the app runs on a laptop with 8 GB of RAM shared with the rest of the system.

GPU-accelerated UI attacks that problem from a different angle. If the engine already draws directly on the GPU with a compact native core, there’s no need to load a browser to paint a color picker or a slider. The result is smaller binaries and faster startups, at the cost of losing the huge HTML and CSS ecosystem that Electron brings along.

How It Works

BUI is organized into two layers. At the bottom is the kit, a core written in C that maintains the full widget tree, processes mouse and keyboard input, calculates the layout, and draws everything following Blender’s interaction rules. On top are the bindings: thin layers that translate Python, Rust, JavaScript, C++, and Dear ImGui into the language the kit understands.

The C Core

The widget drawing code isn’t a reinterpretation, it’s a direct port of interface_widgets.cc, Blender’s actual file that draws every button, menu, and slider. That means the details Blender artists already know by heart, like the numeric field that drags without the cursor touching the edge of the screen, or the menu search that understands “ad cu” as “Add Cube”, arrive intact in any language that uses BUI.

The Bindings

Each binding exposes a different syntax over the same kit. The Python and C side offers a direct API over Blender’s widgets. The Rust side supports both a GPUI-style builder and a React-inspired RSX syntax, and the JavaScript side lets you write components in React or Svelte using HTML and CSS as the UI language, without that implying a real browser underneath.

Damage-Based Rendering

Like Blender, the kit doesn’t redraw the entire screen on every frame. It calculates which widgets changed since the last frame, a value that was dragged or a button that lit up on hover, and only sends the damaged region to the GPU. The rest of the framebuffer stays untouched, which is the main reason an app with this engine consumes battery differently than one with constant CSS animations.

flowchart TD
A["Your app in Python, Rust, JS, C, or C++"] --> B["Language binding"]
B --> C["Kit: C core"]
C --> D["Widget tree"]
C --> E["CPU or GPU drawing engine"]
D --> E
E --> F["On-screen window"]

sequenceDiagram
participant U as User
participant K as C Kit
participant G as GPU
U->>K: moves the mouse over a button
K->>K: calculates which widgets changed
K->>G: sends only the damaged region
G-->>K: returns the composed frame
Note over K,G: the rest of the screen is not redrawn

Practical Examples

The simplest starting point is an unmodified tkinter app. The project itself documents that it runs “unchanged” on BUI’s engine:

import tkinter as tk

root = tk.Tk()
root.title("Hello BUI")
etiqueta = tk.Label(root, text="Panel rendered with Blender's engine")
etiqueta.pack(padx=20, pady=20)
root.mainloop()

This code has nothing special about it, it’s plain tkinter. The difference comes from the backend BUI connects underneath, which replaces the system’s native drawing engine with the kit’s. There’s no console output because it’s a graphical app: what changes is that the window is drawn with Blender’s engine instead of Tk’s native engine.

A second example, this time with Dear ImGui in C++, shows the other extreme: an app that already runs on a real immediate-mode interface engine, which BUI can re-skin with a single compile flag.

#include "imgui.h"

void DibujarPanelMateriales(float& intensidad) {
    ImGui::Begin("Materials");
    ImGui::SliderFloat("Intensity", &intensidad, 0.0f, 1.0f);
    ImGui::End();
}

The code uses the real Dear ImGui API: Begin, SliderFloat, and End aren’t made up, they’re that library’s standard calls. According to BUI’s repository, enabling the corresponding flag makes that same panel get drawn with Blender’s palette and style instead of ImGui’s default theme, without touching a single line of the logic above.

Getting Started

Dependencies before touching anything: git, a C/C++ compiler (GCC, Clang, or MSVC), and CMake. That’s enough to compile the core:

git clone https://github.com/ppmpreetham/BUI.git
cd BUI
cmake -B build
cmake --build build

This block is identical on Linux and macOS if you already have Clang or GCC installed. On Windows, open the command from the “Developer Command Prompt for VS” that Visual Studio installs, so CMake can find the compiler without extra configuration.

This compiles the kit and whichever bindings features.cmake detects as available on your system. To install the specific Python, Rust, or JavaScript binding, the official guide at bui.preetham.top and the repository itself document the exact command per language: clone the repo first with the commands above and follow that guide for the final step.

To confirm the build produced something usable, check that the build/ folder has binaries and run one of the examples in the repository’s examples/ folder. There’s no direct way to verify from the outside the “twice as fast as GPUI” figure the project mentions without running the benchmark they publish in their bench/ folder.

Real Use Cases

There are four developer profiles for whom this graphical interface framework solves a concrete problem.

• Aging tkinter apps: teams with internal Python and tkinter tools who want to modernize the look without rewriting the business logic.
• Tools for 3D artists: software that already targets Blender users and wants panels, shortcuts, and sliders to feel familiar from the first use.
• Rust or React apps without a browser: teams that write frontend in React or Rust and want a native desktop window without packaging a full browser.
• Projects with Dear ImGui: internal development tools that already run on ImGui and want a more polished visual theme with a minimal change.

Comparison with Alternatives

None of these options is objectively better: each one takes on a different cost in exchange for a different advantage.

Common Mistakes and Best Practices

• Confusing BUI with Blender: you don’t need Blender installed or know how to model to use it. The kit is a port of the widget code, not the full suite.
• Assuming it’s a browser: the Rust and JavaScript side uses HTML and CSS as the language to describe the UI, but there’s no browser engine, webview, or network involved.
• Taking accessibility and IME support for granted: the project documents that it still doesn’t have input methods for other languages or accessibility support.
• Mixing up BUI with GPUI by name: they’re different projects by different authors, even though BUI itself compares directly to GPUI in its documentation.

⚠️ Heads up: BUI documents that it still doesn’t have accessibility support or input methods for other languages (IME). This is a point to evaluate before taking it to production.

Going Deeper

BUI’s design distinguishes three “looks” for the same widget tree: HTML mode, styled via CSS for those coming from web frontend; styled mode, its own theming layer closer to a design system; and Blender components mode, the widgets exactly as they look in Blender, with its palette and typography. All three looks share the same layout and interaction engine, what changes is only the final drawing layer.

Another relevant design decision is window hosts: BUI can host its widget tree inside a native operating system window or inside an embedded context, for example a panel within another app. This is what allows using BUI as a tools overlay inside a game engine or another host application, instead of requiring its own window.

Text and font handling also follows Blender’s model: its own shaping system instead of delegating to the operating system’s font engine, which keeps the same visual result consistent across Windows, macOS, and Linux. The same goes for light and dark themes, which aren’t an overlaid stylesheet but part of the same drawing engine that already handles region-based damage.

The rendering layer also chooses between CPU and GPU depending on the platform: the same engine can fall back to a software backend when there’s no available or reliable GPU, something purely GPU frameworks don’t always account for. That flexibility is part of why BUI presents itself as an alternative to GPUI rather than a simple clone, it prioritizes compatibility with old hardware over requiring a modern GPU in every case.

💭 Key point: BUI’s kit isn’t a full Blender fork, it’s a C port of a single part of its code, interface_widgets.cc, compiled as a separate library.

Your next step: clone BUI’s repository, build it with CMake, and run the tkinter example from its examples/ folder to see Blender’s engine drawing a window that isn’t Blender.

Frequently Asked Questions

Does BUI need Blender installed to work?

No. BUI extracted Blender’s widget drawing code and compiled it as a separate library, so it doesn’t depend on having Blender installed or knowing its 3D modeling interface.

What does GPU-accelerated UI mean in practice?

It means the framework draws buttons, panels, and sliders by sending geometry and textures directly to the graphics card, instead of asking a browser engine or the operating system’s native widgets to do that work.

Does BUI replace Electron?

Only if your app doesn’t need a browser’s full HTML and CSS ecosystem. BUI covers React and Svelte in its JavaScript binding, but without a browser engine or Node.js behind it, so DOM-specific web APIs aren’t available.

What languages does BUI’s native UI toolkit support?

Python, Rust, JavaScript (including React and Svelte), C, C++, and Dear ImGui, all on top of the same C core.

How is BUI different from GPUI?

GPUI is Zed’s engine, written and designed for Rust. BUI aims to be multi-language by design and reuses a 20-year-old Blender engine instead of building a new one from scratch. The project itself claims to outperform it, though without publishing complete figures in the README.

References

• GitHub: ppmpreetham/BUI: the project’s official repository and documentation.
• Electron: official documentation on its Chromium and Node.js based architecture.
• Zed: the site of the editor that popularized GPUI as a GPU-accelerated interface engine in Rust.
• GitHub: ocornut/imgui: the official repository for Dear ImGui, the immediate-mode interface library that BUI can re-skin with Blender’s theme.
• Wikipedia: Immediate mode GUI: context on the immediate-mode interface model versus retained mode.

📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Mohammad Rahmani en Unsplash