vello VS imgui

I'm looking forward to doing careful benchmarking, as this renderer absolutely looks like it will be competitive. It turns out that is really hard to do, if you want meaningful results.

My initial take is that performance will be pretty dependent on hardware, in particular support for pixel local storage[1]. From what I've seen so far, Apple Silicon is the sweet spot, as there is hardware support for binning and sorting to tiles, and then asking for fragment shader execution to be serialized within a tile works well. On other hardware, I expect the cost of serializing those invocations to be much higher.

One reason we haven't done deep benchmarking on the Vello side is that our performance story is far from done. We know one current issue is the use of device atomics for aggregating bounding boxes. We have a prototype implementation [2] that uses monoids for segmented reduction. Additionally, we plan to do f16 math (which should be a major win especially on mobile), as well as using subgroups for various prefix sum steps (subgroups are in the process of landing in WebGPU[3]).

Overall, I'm thrilled to see this released as open source, and that there's so much activity in fast GPU vector graphics rendering. I'd love to see a future in which CPU path rendering is seen as being behind the times, and this moves us closer to that future.

[1]: https://dawn.googlesource.com/dawn/+/refs/heads/main/docs/da...

[2]: https://github.com/linebender/vello/issues/259

[3]: https://github.com/gpuweb/gpuweb/issues/4306

Dioxus is working on this with blitz. It's leveraging wgpu through the linebender group's Vello renderer. Still in early stages.

If you're doing advanced compute work (including lock-free data structures), then it's best effort.

https://github.com/linebender/vello/issues/42 is an issue from when Vello (then piet-gpu) had a single-pass prefix sum algorithm. Looking back, I'm fairly confident that it's a shader translation issue and that it wouldn't work with MoltenVK either, but we stopped investigating when we moved to a more robustly portable approach.

There are a number of up-and-coming Rust-based frameworks in this niche:

- https://github.com/iced-rs/iced (probably the most usable today)

- https://github.com/vizia/vizia

- https://github.com/marc2332/freya

- https://github.com/linebender/xilem (currently very incomplete but exciting because it's from a team with a strong track record)

What is also exciting to me is that the Rust GUI ecosystem is in many cases building itself up with modular libraries. So while we have umpteen competing frameworks they are to a large degree all building and collaborating on the same foundations. For example, we have:

- https://github.com/rust-windowing/winit (cross-platform window creation)

- https://github.com/gfx-rs/wgpu (abstraction on top of vulkan/metal/dx12)

- https://github.com/linebender/vello (a canvas like imperative drawing API on top of wgpu)

- https://github.com/DioxusLabs/taffy (UI layout algorithms)

- https://github.com/pop-os/cosmic-text (text rendering and editing)

- https://github.com/AccessKit/accesskit (cross-platform accessibility APIs)

In many cases there a see https://blessed.rs/crates#section-graphics-subsection-gui for a more complete list of frameworks and foundational libraries)

blessed.rs lists these three crates for 2D drawing: - https://lib.rs/crates/femtovg - https://lib.rs/crates/skia-safe - https://github.com/linebender/vello

Vello (https://github.com/linebender/vello) which uses wgpu to render Edit: just saw you require images. Vello doesn't support those yet

How does this relate to Vello? Both target raw-window-handle for winit compatibility. Vello uses WGPU vs piet-glow using GL.

Finally, maybe vello could help you with ideas. It's not production ready yet, but they have some interesting ideas for 2D rendering using wgpu.

include(cmake/CPM.cmake) function(raylib_imgui_setup_dependencies) message(STATUS "Include Dear ImGui") FetchContent_Declare( ImGui GIT_REPOSITORY https://github.com/ocornut/imgui GIT_TAG 277ae93c41314ba5f4c7444f37c4319cdf07e8cf) # v1.90.4 FetchContent_MakeAvailable(ImGui) FetchContent_GetProperties(ImGui SOURCE_DIR IMGUI_DIR) add_library( imgui STATIC ${imgui_SOURCE_DIR}/imgui.cpp ${imgui_SOURCE_DIR}/imgui_draw.cpp ${imgui_SOURCE_DIR}/imgui_widgets.cpp ${imgui_SOURCE_DIR}/imgui_tables.cpp) target_include_directories(imgui INTERFACE ${imgui_SOURCE_DIR}) include(cmake/CPM.cmake) message(STATUS "Include dbg-macro") cpmaddpackage( "gh:sharkdp/dbg-macro#fb9976f410f8b29105818b20278cd0be0e853fe8" )# v0.5.1 message(STATUS "Include fmtlib") cpmaddpackage("gh:fmtlib/fmt#e69e5f977d458f2650bb346dadf2ad30c5320281" )# 10.x message(STATUS "Include raylib") cpmaddpackage("gh:raysan5/raylib#ae50bfa2cc569c0f8d5bc4315d39db64005b1b0" )# v5.0 message(STATUS "Include spdlog") cpmaddpackage("gh:gabime/spdlog#7c02e204c92545f869e2f04edaab1f19fe8b19fd" )# v1.13.0 message(STATUS "Include rlImGui") FetchContent_Declare( rlImGui GIT_REPOSITORY https://github.com/raylib-extras/rlImGui GIT_TAG d765c1ef3d37cf939f88aaa272a59a2713d654c9) FetchContent_MakeAvailable(rlImGui) FetchContent_GetProperties(rlImGui SOURCE_DIR RLIMGUI_DIR) add_library(rlimgui STATIC ${rlimgui_SOURCE_DIR}/rlImgui.cpp) target_link_libraries(rlimgui PRIVATE imgui raylib) target_include_directories(rlimgui INTERFACE ${rlimgui_SOURCE_DIR}) endfunction()

Immediate mode is a fuzzy concept, as witnessed by this writeup: https://github.com/ocornut/imgui/wiki/About-the-IMGUI-paradi...

It's fun to see the evolution in e.g. these examples of image loading for Dear Imgui:

https://github.com/ocornut/imgui/wiki/Image-Loading-and-Disp...

DirectX9 will even load the image for you, DirectX11 okay we get a few more structures to fill out, DirectX12 is where it goes off the rails and we are filling out a bunch of UNKNOWN DONT_CARE JUST_DO_IT. Then of course Vulkan is the one that gets the big fat "this probably won't actually work for you" warning.

I understand whats happening, but you know sometimes I just want to display a fucking image.

ImGui is engine/GPU agnostic

Themeing isn't a just a retained mode thing, you can do wonders with immediate UIs, even thought (dear)ImGui doesn't provide much, you can still do wonders: https://github.com/ocornut/imgui/issues/707#issuecomment-362...

More on that topic: https://www.youtube.com/watch?v=Z1qyvQsjK5Y

Bonus: If you want to make desktop app with UI, then this is another great C++ library and it's also simple to learn as well. https://github.com/ocornut/imgui.

AFAIK the Rust equivalent to C++'s Dear ImGui is egui.

They use a Dear ImGui, a C++ GUI library.

Aside from bugs and driver issues, Wayland has some unfortunate design limitations. For example, Dear ImGui multi-viewports don't work because "Wayland doesn't let application read or write windows positions."

https://github.com/ocornut/imgui/wiki/Multi-Viewports

This is a feature available on Windows, macOS, and of course X11. Making choices like this means desktop Linux becomes even more of a weird island that nobody wants to support.