danlcaza

See benchmarks done by LIGO-Virgo-KAGRA collaborations https://news.ycombinator.com/item?id=45955957

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.

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

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.

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.

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

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.

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.

Heap allocation is necessary in real-world scenarios because it allows a tree of potentially derived widget types to be manipulated easily. This is precisely how any robust GUI library is implemented.

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.

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/

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.