ImGui Advanced Rendering

[HDAKFD]

Details:

I am trying to replicate certain Skia functionality with ImGui

There is few things that i require the application to include so i am asking if you think i should rather keep using ImGui and try replicate these skia functions, or just move on the bulky skia.

The factors i am trying to remake:
- Path Clipping (Polygons, Circles, Rectangles with Rounding)
- Using Gradients in any object, adding multiple gradient "points", For example AddRectFilledMultiColor has one each corner
- Having rounding in polygon objects.
- Shader for blurring textures && objects

I know that ImGui isn't designed to handle these, but i think these are the factors that would allow ImGui to compete with these bulky frameworks such as Skia. I know that skia uses shaders for pretty much every function it contains, while imgui runs on single shader setup, making it way more limited but more compatible for different platforms.

[ocornut]

I have no intention nor desire to compete with Skia or frameworks of that kind.
I am not sure what you are asking precisely. You can already perform many things by manipulating vertexes directly. But general support for highly primitives of that sort is likely to be out of scope of dear imgui. People could always attempt to create a helper library over dear imgui.

[ocornut]

i am asking if you think i should rather keep using ImGui and try replicate these skia functions

It's up to you really. If you are confident in your ability to replicate them, why not. But I don't think we can help you much with it as it's not much in our own development path.
Also consider other more advanced vector drawing libraries such as NanoVG, maybe you'll find something you can use along with dear imgui, depending on your precise use case.

One thing that we are likely to introduce this year is a concave polygon drawing function, but that's still very far off from the list of things you are mentioning.

[stergiotis]

I am currently working on instrumenting the DrawList class to capture the drawing commands. Think vector and text primitives instead of vertices and textures. See #6384 for a similar proposal.

@ocornut : Would you be interested in having an alternative #ifdef'ed implementation of DrawList that stores the commands in flatbuffers (or something similar)? Does it have a chance to get accepted upstream?

My motivation is three fold: I would like to get
a) a native go binding of imgui (w/o cgo) using https://github.com/tetratelabs/wazero and https://ebitengine.org/;
b) a fully fledged desktop app quality Skia backend with text layouting and rendering done by Skia (and therefor harfbuzz etc.);
c) the possibility to implement a mobile app using react-native-skia or flutter.

I highly appreciate and respect the self-contained and portable codebase of ImGui. But IMHO a few #ifdef and macros may get a long way (no need for virtual function calls in DrawList),

[the-goodies]

My motivation is three fold: I would like to get a) a native go binding of imgui (w/o cgo) using https://github.com/tetratelabs/wazero and https://ebitengine.org/;

I have a very rudimentary prototype using ImGui with wazero (last time I tried was last spring), but I wasn't satisfied with the performance, so I dropped the idea of making full ImGui bindings with Wazero to avoid CGO. Maybe things have changed since then in terms of performance, but have you actually tried? If performance was decent, it would be great to have such bindings in Go.

[stergiotis]

My motivation is three fold: I would like to get a) a native go binding of imgui (w/o cgo) using https://github.com/tetratelabs/wazero and https://ebitengine.org/;

I have a very rudimentary prototype using ImGui with wazero (last time I tried was last spring), but I wasn't satisfied with the performance, so I dropped the idea of making full ImGui bindings with Wazero to avoid CGO. Maybe things have changed since then in terms of performance, but have you actually tried? If performance was decent, it would be great to have such bindings in Go.

I made some measurements with wazero in Dec 2023 which were "encouraging" (on amd64). Note that vertex generation/drawing would not be executed in Wazero but in ebiten.

My effort ist currently focused on developing a CGO-free go binding using RPC over IPC (currently using pipes in Linux). As long as there are not too many visible interactive elements that need round-tripping the performance so far has been good enough for data-intensive desktop applications.
My code is available in https://github.com/stergiotis/boxer/tree/main/public/imzero. The necessary C++ client "interpreting" the ImGui commands is not yet open-sourced (plan todo soon). Overall the design resembles react-native with the known limitations. Using efficient binary formats and good API design goes a long way and may prevent round-trips altogether.

[stergiotis]

Skia binding code is now available open-source (MIT): https://github.com/stergiotis/imzero_client_cpp
Posted a screenshot in ImGui Gallery Issue #7959 (comment).

[native-m]

I'm working on a lightweight GPU vector graphics library that can be integrated nicely with ImGui (or standalone).
It uses exact coverage AA technique to achieve accurate AA and does not use triangulation.
It is not finished yet, there are many things that need to be done and fixed (no imgui integration currently).

Here is a minimal demo:

EDIT: Repo link