search

ocornut / imgui

Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
MIT License
59.4k stars 10.12k forks source link

ImGui Advanced Rendering #7318

Open HDAKFD opened 7 months ago

HDAKFD commented 7 months ago

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:

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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.