Our great sponsors
-
JUCE
JUCE is an open-source cross-platform C++ application framework for desktop and mobile applications, including VST, VST3, AU, AUv3, LV2 and AAX audio plug-ins.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
rerun
Visualize streams of multimodal data. Fast, easy to use, and simple to integrate. Built in Rust using egui.
-
pasvulkan
Vulkan header generator, OOP-style API wrapper, framework and prospective Vulkan-based game engine for Object Pascal
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
makepad
Makepad is a creative software development platform for Rust that compiles to wasm/webGL, osx/metal, windows/dx11 linux/opengl
> Juce has a CoreGraphicsMetalLayerRenderer which I believe uses Metal to render CoreGrapghics primitives.
This class is part of a JUCE demo app, and you can read the source code to it if you want. [0] It uses CoreGraphics to render the graphics on the CPU, and then uploads it as a texture to the GPU so it can be used as a CAMetal layer. So, no, the graphics are still rendered on the CPU, with compositing being handled on the GPU.
> For example, I heard that UE4->UE5 removed the GPU tesselation support
I know it's confusing, but GPU tessellation is a completely different thing. The word "tessellation" in graphics means "turn into triangles". In a 2D graphics context, we're turning splines and curves and 2D shapes into triangles. In a 3D graphics context, GPU tessellation refers to a control cage mesh which is adaptively subdivided. These two have nothing in common except that triangles come out the other side. I am not aware of anyone who has tried to use GPU tessellation to render 2D graphics.
GPU tessellation failed for a large number of reasons, but slow performance was one of them. So, you know, doing this sort of work efficiently on the GPU is still an open research problem. Just because it's not efficient to do it on the GPU does not mean the performance overhead is negligible. For rendering big complex vector graphics, tess overhead can easily outweigh rasterization overhead.
[0] https://github.com/juce-framework/JUCE/blob/4e68af7fde8a0a64...
This is known as a “multi-channel signed distance field”, or “msdf”.
https://github.com/Chlumsky/msdfgen
Not true, even if you add Rust. egui was released earlier: https://github.com/emilk/egui
And egui isn't tied to Apple proprietary frameworks.
ImGui is mainly used for debug rendering, but if you browse the screenshot threads, there quite a few 'end user applications' among them:
https://github.com/ocornut/imgui/issues/5886
Egui seems well suited to render even tens of thousands pointcloud with wgpu backend.
[0] https://github.com/rerun-io/rerun
This guy Bero1985 wrote the 3D library / engine some years that has extensive 2D features including UI that uses SDF among the other things [0].
[0] - https://github.com/BeRo1985/pasvulkan
Oops I forgot to mention that one. They also have a pretty interesting cross-platform GUI framework using it: https://flutter.dev/
My rui library can render UIs at 120fps, uses similar SDF techniques (though uses a single shader for all rendering): https://github.com/audulus/rui
Is their GPUI library open source?
And what was learned from Flutter has produced something I consider even more interesting: Compose UI (https://developer.android.com/jetpack/compose) and JetBrains' Compose Multiplatform (https://www.jetbrains.com/lp/compose-mpp/)
I haven't found good platform accessibility API bindings for C#, so right now it just has narration support, adjustable text size/contrast, and full keyboard navigation. I'm hoping that later on in my project's development process I'll have the budget to hire someone to try and fully integrate with the platform APIs - it's designed so it will be possible by pushing updates to the retained model.
The way it works is that it has an immediate mode API (see https://github.com/sq/Libraries/blob/0ca01d949e3df5fabb1440d... for a simple example of the API) and then under the hood it uses a lightweight retained-mode graph, which means that when it's more convenient you can just write more traditional classes and components. In practice most of the UI I've written for my main project is a mix of both models, like for example an editor popup window uses IMGUI-style API while the items in a virtual listbox are represented by a small custom component.
It does have a full imgui-style layout engine under the hood instead of doing retained-mode layout, so it's able to fully re-generate layout from scratch every frame, and to minimize page tearing there is a system where components can request a second relayout pass (typically used for things like text autosize).
Here's a more complex mixed-mode example from one of my development tools: https://gist.github.com/kg/6a6ba42d5019b546858a2b18751de019
Beyond the rendering which as noted is nothing that hasn't been done before (in general) the inherent OT/multi user + tree sitter functionality is something that entices me.
I'm surprised nobody pointed out lite/litexl here either it's rendering of ui is very similar (although fonts are via a texture; like a game would) and doesn't focus overly on the GPU but optimises those paths like games circa directx9/opengl 1.3
https://github.com/rxi/lite/blob/master/src/renderer.h
I tried this, using https://makepad.dev our GPU accelerated UI and renderstack. And unfortunately it wasn't a great experience. Text popping forward for whatever reason is not really an improvement (i tried indent depth, syntax highlighting reasons, cursor behavior). Maybe 'veeeeery' subtly could do something, but otherwise you dont want it to break visual symmetry as we are used to