are we moving from dear imgui to egui?

[brigazvi]

if so, why?
we have minimal resources. is it a good idea to spend it on changing things that already work instead of all the missing features?
(I don't have any right to ask, because I contributed almost nothing. but I am curious what was the rationale behind the decision.)

[ctrlcctrlv]

We are. @MatthewBlanchard is working on it. I am writing MFEKpreview using egui. Due to MFEK's modular nature, it takes no more resources to write MFEKpreview with egui than imgui.

The problem is, things aren't working well at present. MFEKglif runs horribly on macOS, many workarounds are needed to get it to run, including installation of the Vulkan SDK.

And even on GNU/Linux, Vulkan can be a pain. We also rely on an outdated library called Skulpin which frequently breaks and which has no upstream maintenance.

Hope that answers your question. See also:

• Resizing is wonky. (On macOS, missing frames cause scaling. On GNU/Linux, a blackout effect occurs.) #322
• VulkanSDK post-1.2.198 is broken on macOS #323

[ctrlcctrlv]

Oh, sorry. @ocornut this is a very old historical issue but everything we want to do with OpenGL and Skia wasn't possible on macOS which led to initial port to Vulkan.

See #2.

[ctrlcctrlv]

Because Apple has no plans to fix it, and egui-skia supports Metal as well, it's much easier for us to just choose the graphics API that is best for the end-user rather than the current custom setup which requires us to settle on one or else take over maintainership of a complex topic a font editor shouldn't have to deal with.

[ctrlcctrlv]

I like ImGui and if this were a C++ project sticking with it would make a lot of sense but it's Rust so in the interest of lowering graphical glitches and maintenance issues, that's basically why choosing egui is better as it more easily supports building w/Metal, OpenGL, Vulkan, D3D and requires no custom code from us which I'm not that great at even writing and which shouldn't be custom to us anyway. Hope that clears it up. :)

[ocornut]

There is a Metal backend for Dear ImGui and you can use Metal backend on Mac and e.g. DX11 on Windows or anything else, the difference would account for a dozen of lines.

But perhaps you are worried about maintaining the "create window and swap buffer" part of the app which is outside the scope of Dear ImGui itself but provided in each examples/ app. In that case it's interesting feedback to know about! I can understand how for teams not going from graphics-programming that part may be tedious to think of, and there would be value in abstracting it. I believe as Dear ImGui is geared toward attracting more non-games people it would be make sense. But typically people would use SDL or GLFW as a shared platform, and can a different renderer backend for each platform.

There are many mini-frameworks variants listed on our wiki, but we use a little wrapper on our side for test-suite related apps (imgui_app: https://github.com/ocornut/imgui_test_engine/blob/main/shared/imgui_app.h, demo app with setup of test-engine https://github.com/ocornut/imgui_test_engine/blob/main/app_minimal/app_minimal_main.cpp) which allow this window creation. This is also what GLFW and SDL generally do.

Thanks for the details, the feedback is helpful!

[ctrlcctrlv]

But perhaps you are worried about maintaining the "create window and swap buffer" part of the app

Yes that is exactly right.

I can understand how for teams not going from graphics-programming that part may be tedious to think of, and there would be value in abstracting it.

I certainly think so! We know we need GPU support for most of MFEK's tools, because font glyphs can have thousands of points and trying to do that in the CPU with something like Cairo or a Rust version of it is just slow and painful for users. This was actually my first GPU application and only came about due to this necessity, I have never worked on a videogame or anything close unless we count a TUI Snake clone I wrote in 2012 when I was learning Python. :)

[MatthewBlanchard]

One of the biggest reasons we're moving to EGUI:

It's incredibly similar to imgui, but Rust native. It also has web renderers that we can leverage.

Using IMGUI from Rust kinda sucks. There's a bunch of macros for casting strings, and it's a pain in the butt.

[ocornut]

Dear ImGui also has web renderers.
I thought the macros were removed already?
We have a maintained string_view/ branch to support non-zero-terminated strings.

We developed dear bindings with the intent of vastly improving the quality and maintenance of auto-generated backends (it can generate e.g. a C api with full comments in header).