Imgui: .NET Port ImGui

[xposure]

Near completion of most of the port for ImGui to .NET. I would say I'm around the 90% mark and I'm currently working on the demo side to finish off any pieces I missed along the way. Here are some random points of interest.

• Currently targeting MonoGame but I will remove this requirement to keep it in line with ImGui
• Ported stb_textedited, may be useful for others looking for text input logic for .NET
• Switched from stb truetype to freetype2
• The screen shot below is rendering around 0.7ms in release mode (albeit on a higher end pc).
• Still issues with input editing for sliders
• Pixel snapping issues causing things to appear blurry
• Minor issue with treeviews and retaining their state open properties when selecting other nodes
• Appears to be an issue with the scaling to the window
• Code will be put up on GitHub in the near future

[ocornut]

Nice work!

Since it looks like you have literally ported all the code and forked the project, may I kindly ask that when you create a new repository you give it its own name?

Its totally fine to refer to dear imgui here and there, but I would like it to be clear to people that this is a fully hand-converted version of the code and not just a regular imgui binding thats using and in sync with the core library. This is particularly important as they will likely drift apart further as time goes by, so it is good to clarify the difference.

[dumganhar]

Awesome 👍

[xposure]

I still don't really know what my intentions are for this so I can just sit on it for a little while. If interest comes up I can go ahead and make it more official. As for the code diverging, its almost a 1 to 1 port with a few minor exceptions.

I used a singleton and changed most of the static methods to instanced, so you access it by doing ImGui.Instance, most of the global functions were all moved to this class. Apart from this most of it was copy and paste and converting to c#, I simply changed all the pointers to integers and passed an extra variable in where needed and used the integers as indexers. This has allowed the code to be built without pointers/unsafe modifier. I have also used .NET char and string where applicable removing some redundant code.

Keeping the code in sync should be relatively easy just by going through ImGui's commits and applying the same code to this port.

[xposure]

@ocornut Did some profiling and I found that in my draw method, internal static ImVec4 ColorConvertU32ToFloat4(uint @in) takes up 1/3rd of my draw routine. I reduced this considerably by converting it to a lookup table, thought it might help ImGui as well. I didn't want to create a new issue because I wasn't sure if it would directly relate to c++ since it might be running SIMD on it.

        private static float[] u32FloatLookup;
        internal static ImVec4 ColorConvertU32ToFloat4(uint @in)
        {
            if(u32FloatLookup == null)
            {
                const float s = 1.0f / 255.0f;
                u32FloatLookup = new float[256];
                for(var i =0; i < 256; i++)
                {
                    u32FloatLookup[i] = i * s;
                }
            }

            var x = u32FloatLookup[@in & 0xff]; @in >>= 8;
            var y = u32FloatLookup[@in & 0xff]; @in >>= 8;
            var z = u32FloatLookup[@in & 0xff]; @in >>= 8;
            var w = u32FloatLookup[@in & 0xff];

            return new ImVec4(x, y, z, w);
            //return new ImVec4((@in & 0xFF), ((@in >> 8) & 0xFF), ((@in >> 16) & 0xFF), (@in >> 24)) * s;
        }

[ocornut]

Keeping the code in sync should be relatively easy just by going through ImGui's commits and applying the same code to this port.

Except that realistically you won't do it! Because it is sort of a lifetime commitment (not being critical, its just how things happens, a few refactor/cleanup down the line and it'll be too much work for you. ImGui is still a rather active project.). Also you probably have changed some properties of ImGui - performances coming to mind - so from my point of view where I am already overloaded with work I can't deal with the increased confusion/load that some people using a different code-base come here expecting support (it will still happen and that's fine

Sorry if that sounds like party-pooping. It's cool that you're doing this work and you should do what you want, but I need to be NOT involved :)

[ocornut]

ImGui never calls ColorConvertU32ToFloat4 so that relates to your renderer. Not sure why your uint is a reference, it probably affects performances a lot. I don't know how C# choose whether a type of heap/gc-ed versus stack type but all those ImVec4 should be on the stack. But then, optimizing your C# code is that last thing I want to get into and that is sort of the point of my intervention.

[xposure]

@ocornut It is on the stack, @in is because like I said I did a 1 to 1 conversion of your code, in is a reserved word in .NET so to use the same name you must prefix it with @. If I wanted to pass it by ref I would change the signature to ref uint @in.

Anyways I can see you have no interest and some animosity towards this port. I didn't ask for help and while ImGUi doesn't directly call this method someone else's renderer might (like mine) and while I can't be certain that your C++ compiler isn't turning that in to some sort of fancy SIMD instruction a shift and lookup is much faster than what it was.

This can be considered resolved/closed, thanks for making ImGui, I learned a good bit from it.

[ocornut]

My C# is rusty I thought @ was ref. I wonder why that function would be slow though if you are running it on 10k+ vertices it certainly have a cost. It is truly a waste since in reality 90% of the color will be pulled from the style and be the same (e.g text color). There was a request to allow overriding the ImDrawVert layout so end-user could provide float4 if they wanted, it is sort of possible to still do it in c++ if we use macros (because accessors would have cost in debug) and may do that eventually.

For batch conversion going via a lookup table is it probably beneficial since the cost of filling the cache with 1k of float will be amortized, however for a once-in-while "random" call it may not be beneficial so I don't think it would be worth using such table for the general case. We could setup a test to verify that with some effort (not trivial to test accurately). I would suggest having the cache local to your renderer in this case and inline the function. I don't really know enough about C# to tell where that time is going. Inlining the code will probably help.

Another way would be to see if you rendering/shader can just take U32 in the first place to avoid that conversion and extra bandwidth.

Truly sorry it that sounded like animosity it wasn't my intention, I'm just trying to protect myself from extra work (it's been difficult to focus on new features for me, every week-end comes with small questions/requests and they add up and I never get to work on actual big features. In the grand scheme of things I need to say no to whatever is distracting me from main line of work). If you release this we'll add it to the Links and Bindings section.

[prime31]

@xposure is this project still active? Is it available on GitHub yet? I was just going to make MonoGame bindings for the native lib but if you ported it to C# that would be even better.

[xposure]

@prime31 As I previously mentioned there was a bit of resistance towards the project and it wasn't something I wanted to work on that people didn't feel was needed so I discontinued working on it.

With that said I have had several inquiries over the topic so I will look at putting the code I have up, perhaps someone else will get behind it as its mostly done.

[prime31]

@xposure if you do happen to put it up please do post back here or shoot me a message. I would much prefer to not have to deal with a C++ lib and a C wrapper on multiple platforms. I personally don't much care what others opinions are so the resistance aspect means nothing to me.

[xposure]

@prime31 Decided to post the code AS-IS in case anyone wants to play with it. I left off porting the SampleDemo so all core components are in place.

https://github.com/xposure/ImGuiSharp

[darthdeus]

@prime31 Did you aim to include this as part of Nez? Also note there is https://github.com/mellinoe/ImGui.NET