Show HN: Brisk – Cross-Platform C++ GUI Framework: Declarative, Reactive, Fast (github.com)

The pricing information will be made public at the time of the next Beta release. Currently, the framework is refining Linux support, with plans to include mobile platforms as well.

Thank you for the feedback. The framework was originally built with exceptions always disabled, and it is currently being reworked to support both modes: exceptions enabled and disabled. Some approaches definitely need to be reconsidered.

An alternative approach is to use the rcnew macro, which wraps a pointer in a shared_ptr under the hood. Details on the implementation of rcnew can be found at: https://www.kfr.dev/blog/three-cpp-tricks/

Specifying things declaratively within the language itself goes far beyond simply constructing widgets by calling library functions.

This technique is utilized in modern frameworks like Jetpack Compose, Flutter and SwiftUI and unlocks several powerful features, such as flexible data binding and the ability to rebuild the widget tree on demand, features that would be quite difficult to implement in other libraries.

Good point about the non-Windows screenshots, but the Brisk library apps look exactly the same (except for window decorations and DPI scaling) on any supported OS due to its custom pixel-perfect graphics engine and its own font engine (based on FreeType and HarfBuzz, of course). Key bindings are not supported at the moment. The calc example shows a possible workaround for this.

Thank you for the feedback. C++ isn't a language that makes data binding implementation easy, but C++20 introduces some useful features that could be leveraged for this purpose.

> Though unfortunately since it's not lGPL or MIT, it doesn't look like I could use it anyways.

Why not. They also intend to have a commercial license. Don't event want to consider paying?

> I use Qt myself and one of the best things about the framework and toolkit is the UI tooling that allows me to drag and drop and visually create my UIs in the UI Designer app.

But then it's not trivial to write responsive/adaptive applications. In contrast, QML makes it extremely easy to build such apps.

I used to build UIs in the designer as well[1] but after studying QML there's no going back. Here's a new project I program solely in QML (and C++ for the logic)[2].

[1] https://github.com/nuttyartist/notes

[2] https://www.get-vox.com/

I don't think open source GUI toolkit developers should be expected to handle accessibility until OS vendors spend some of their billions of dollars to develop a reasonable cross-platform API.

Accessibility features are planned and will be included in one of the upcoming major releases.

” nothing I personally dislike more than apps that don't use the platform's native UI”

I’m not sure if this is universally applicable dogma. Games generally apply their own UI regardless of platform.

Web apps generally do as well.

I do realize there is space for apps with least surprise per platform, but it’s not obvious to me if an app benefits from platform standard UI any quantifiable way.

There are many professional applications (not games) that use custom-drawn UIs. Examples include video editing software, 3D modeling tools, and professional audio plug-ins. These applications may rely on a significant amount of platform-specific APIs for better OS integration, yet they maintain a consistent appearance across all supported platforms.

This is definitely a great feature for future versions and is already in our backlog, though it will require significant effort to implement. Thank you.

I think it just means the texture image for the widgets are loaded into gpu memory space instead of a traditional framebuffer that gets copied to the gpu.

I dabbled in 3D for a while too and was astonished how much 2D stuff there is for it.

> When these 2D GUIs say "GPU-accelerated", does that mean they are doing the same thing you would do for 3D

Yes. Nowadays all modern desktop interfaces—Aero/Metro/WinUI2/3 on Windows, Aqua/Cocoa on macOS, KDE, GNOME, XFCE, LXDE, and even some window managers on Linux—are 'GPU-accelerated'.

Every window is a quad of two triangles. There's no real vertex shading since it's all orthographic as you mentioned. The framebuffer for each window is exactly the x:y resolution for that window (macOS does some interesting 1:2 resizing here sometimes). The 'fragment shaders' is where the GUI toolkit comes in, writes to these buffers, and does any decorating where needed.

The final framebuffer is exactly the resolution of the entire monitor (again, macOS may do some weird 1:2 resizing).

The framebuffers of all windows on-screen are composed into this one. This is where things like transparency effects, the window and scroll controls, drop shadows, any 'rounding off' masks (used to great extent in macOS), and funky 'frosted glass'/'reflection' effects come in. This gives the effect of windows behind/in front of other windows. This is also when partially/fully off-screen windows are clipped/culled against the viewport frustum (not really a frustum but more a cuboid since it's not a perspective).

Once all this is done, you have a frame that's ready to be piped down the display cable into the display.

There are some other facets muddying the water like HDCP DRM protection for the entire framebuffer or some window framebuffers, variable-rate refresh, and so on. The former is how PrintScreen on Windows returns a black screen for some windows—that's HDCP in action.

Most of the drawing work of a GUI is drawing text, shape paths, and images. A GPU-accelerated UI layer draws these using GPU commands. It's not exactly the same as making an ortho 2D scene, but conceptually that's pretty much it. Often it means using crude geometry (such as a quad per glyph in a text renderer, or a "ribbon" of quads to cover a curve) and using a shader to draw the glyph or curve itself.

For a simple example, think of a rounded rect. Typically this would draw as a quad (a pair of triangles), and a shader would calculate the rounded corners.

There's also a lot of compositing and clipping that happens in a UI (e.g. a large widget inside a scrollbox) which is challenging to do on GPU as these get nested.

Modern 3D rendering APIs (like Metal, D3D12 and Vulkan and D3D11 to some extent) offer far more flexibility than the traditional triangles-and-materials approach. Rendering in Brisk leverages complex shaders that directly process drawing commands on GPU, avoiding the intermediate step of converting them into a list of triangles.

For text rendering, Brisk uses FreeType to render glyphs on the CPU and caches these glyphs in a GPU-accessible texture, which is reused for improved performance. This approach is common among GUI toolkits for handling graphics and fonts.

In addition to this, Brisk employs SDF (signed distance field) graphics wherever possible, which are entirely computed in shaders.

I second that. I used Dash for a while. Although it's nice to have everything wired up for free, the code quickly becomes a mess as soon as you try some more complex things (or you put everything in one function and got a big super nested structure, or you build a lot of small components and quickly get lost in a sea of small functions).

I'd rather build the HTML myself.

[1]: https://dash.plotly.com/

It isn't really that important to have a declarative UI, making the UI is rarely the time consuming or difficult part of making a program. An extra markup language for a UI adds bloat and ambiguity. Now you're learning a different ad hoc language and trying to get around its quirks just to be able to feed in data that could have been done directly with functions.

Unfortunately, I didn't come across your library when checking for name collisions. You're right, this is purely a coincidence.