A Critique of GPUI

The author argues that GPUI and egui state models are not practical for building complex desktop applications. They explain that these frameworks aim to answer the question of what runs when a value changes, but this approach does not scale well. GPUI uses an "immediate and retained mode" framework, retaining state in entities and triggering a rerun when state changes.

However, it requires an explicit notification for state changes, and without write barriers, it cannot efficiently determine which fields have changed. As a result, GPUI often re-renders every view, even if only a small part of the UI has changed.

The author ran benchmarks with GPUI to test the performance impact of sparse state changes in large UIs. They found that changing one label in a UI with 3,000 live rows resulted in 8.4 ms of rendering time, and this cost increased by about 3 ms per 1,000 live rows. In comparison, a hand-written equality guard reduced the label update time to 0.9 µs, demonstrating the limitations of GPUI's state model, especially with more expensive layout operations.

While Zed, a popular application built with GPUI, feels fast, the author notes that it is a relatively simple app compared to the complexity of real-world applications.

The author also points out the drawbacks of egui's state model. Both GPUI and egui require developers to manually create boundaries for state projection, as the frameworks do not automatically optimize for this. This manual effort can lead to complex and difficult-to-reason-about code structures.

In conclusion, the author believes that while GPUI and egui are impressive projects, their state models are not suitable foundations for building complex desktop applications. They argue that the limitations of these state models become apparent when dealing with large UIs and expensive layout operations. They suggest that signal-based frameworks like the one they built (zgui) may offer a better approach for native desktop applications.