August 10, and ideas

[ocornut]

August 10 is the date last year I put ImGui 1.0 online, following a month of preparation!
I will need to step back a little from ImGui and I thought the first year anniversary would be a good date for that.

I really enjoy working on it and I have hundreds of ideas of ways to move it forward. Then reality hits: I've been slowly consuming my savings putting time to work on this and other free projects. At this point in my life I really need to try to focus on finding something I can make a living of and this means I need to put some things aside, free up time and reduce my already charged cognitive load. Sustainable game development is enough of a lottery that I can't afford to make it harder for me.

My hope was that some of the larger companies using ImGui would be able to contribute to the Patreon up to a point where I could justify spending a few days a week working on it, but it is probably not going to be the case. I am very very grateful of everybody already helping with the Patreon. It wouldn't be reasonable to expect more and I certainly don't expect individuals to add more to the pot.

So while I won't abandon ImGui and I know myself well enough to know I'll always be doing things on it, I need to set a date to make a mental transition of softening my involvement. So instead of waking up thinking "shit I need to fix this bug or add this feature" I'll be more relaxed about it. I may come back to focus on it occasionally depending on my situation.

Omar

Development wise, some upcoming themes I have in my mind:

• (DONE!) Finish the anti-aliased branch.
• (DONE!) Which means re-factoring the rendering data to be more future-proof. Switching to indexed rendering already broke rendering in the AA branch so it is the perfect time to do that transition. We should be able in the future to provide high-level information on windows so that virtual canvas, networked output is easier to work with. Also consider the possible transition to use a dynamic font atlas, perhaps the user would get e.g. a texture dirty-rectangle.
• (DONE!) The current columns implementation is currently performance-poor because it keeps pushing primitives in submission order with different scissoring settings, whereas each column should append to its own list and they are merged-flattened at the end of the column set. One advantage of switching to indexed rendering is that it is now much easier and cheaper to do that. I want to think that feature through just in case it has an effect on the rendering data (it might not) so all the breaking changes can be done once only.
• Add a framework for testing. If more people have to work on ImGui testing needs to be more thorough. I don't know what form it would take yet.
• Add a framework for generating screenshots/animations for given pieces of code. This is probably going to be done along with the "testing" framework. I would like the ImGui documentation to be a very visual, well organized listing with C++ code on one side, screenshot (or animated GIF) on the other side and tags + commentary. I think this will easily convey a lot of ideas and tips about ways to use ImGui.
  Update: I've created some helper to help me take manual screenshots and its been very helpful in the past few days. This will probably evolve into such framework.
• (DONE!) Various improvements with font (Add font fallback support, just like what windows does. #182 AddFontFromMemoryTTF transferring ownership #220 Using Icon Fonts in current Font #232 Font character spacing settings #242 are all related, the key is figuring a way to do the initialisation that is flexible enough). And considering making the texture a dynamic atlas (this later part is much less a priority).
• Allow all "value - label" widgets to be displayable in a variety of combination (e.g. "label widget", "label\nwidget" with variety of expressive layout options and alignments. Devise better methods to express and manipulate the size and alignment of one or multiple widgets. Currently the PushItemWidth(...); Widget(); PopItemWidth() idiom is way too verbose. Enable simpler and better horizontal layout.
• Resizing separators, a way to separate e.g. two child windows and resize them. That would be a more flexible generalization of the concept used by columns.
• Better columns, sizing options, columns header, scrolling with non-scrolling headers, sorting, re-ordering. It's all sort of feasible but should be natural first-class citizen.
• Better methods to handle simple alignment issues. The checkbox in the demo window with "No title bar" "No resize" etc. is a pattern that is hard to solve perfectly in one pass with the current available features. The approach of ImGui for some problems like this one is often "who cares just add a constant" but it'd be nice to have extra layout features to allow for it more elegantly.
• Shortcuts for menus and a general shortcut system.
• (DONE!) Keyboard navigation and usage.
• A generic iterator/data access scheme so that API like Combo or ListBox can be used with sparse list of value (currently Combo assume linear sequence so the user needs an extra level of indirection if their value are sparse).
• And the visual redesign..

I don't know when those things will be done. Probably not by August! if you feel like helping with something let me know!

[Pagghiu]

Hi Omar,

I have been reading this post and I want to comment both the first and the second part.
Regarding the first part it's clear that the time you can spend on improving the library is proportional to the money you can make with it.
Have you already thought of changing the way you're "marketing" the library?
Let me try to explain what I mean.

0. Imgui needs a website that should at least contain latest up to date downloads, donations links, cool shots/video, roadmaps, who's using it etc.

1. You may be under-estimating the power of this library, it's not just for debug visualisation or game/tools/editor UI. I think what I was able to achieve in a few months of usage/customisation is really cool. Have you seen my latest shots at Gallery: Post your screenshots / code here (PART 1) #123 ? Probably a video instead of some shots would make it more clear.
   I see IMGUI as a general cross platform UI library. The current showcase example is cool, but spending some time in building some "real world" examples would open a whole new world.

2. Put some effort on making the demo/shots of the library more visually appealing.
   I'm sure this will increase usage A LOT, and more popularity, more possibility of money making for you.

3. Ask for money on specific features. Less Patreon and more Kickstarter. Something along the line of:
   "Feature proposal XYZ: Create the TextEditCheckboxMultiline Widget" - Target: 500$
   When target is reached, you will implement it in 1/2/3/whatever months timeframe was stated in the proposal.
   A big company that absolutely needs feature XYZ will be a "sponsor" for it, more or less like LuaJIT (see http:https://wiki.luajit.org/Open-Sponsorships )

4. Spend some time to integrate and keep up to speed some cool forks I've seen around here to expand functionality (the remoteimgui is really cool)

5. Make some ready to use samples that show integration with other UI frameworks (I've personally done it with MFC on win / Cocoa on mac), without requiring strange "game programmer" libraries like glfw etc.

6. Create wrappers for other languages like C# so that people can use it in Unity or other cool engines from webgl/javascript via emscripten!.

7. Ask for help! Try to write down a proper structured roadmap and/or thing you would like to do in a way that a contributor could try to send a meaningful pull request to the project.

Regarding the technical part I think the priorities should be

• Font handling: this will make the ui extremely more appealing and flexible
• Visual Redesign: this is important to show the power of imgui.
  Just adding some colors, with icon fonts and using a proper text font makes everything so much cool :)
• Widget Alignment: we've discussed this a few times even if I've always been able to place controls where I want with some more ad hoc verbose code.
• Everything else in any order.

[extrawurst]

@Pagghiu at least wrapping (point 6) is already done in form of a c-api (https://github.com/Extrawurst/cimgui) using this is easy from most of the other languages.

[ocornut]

They are all good ideas but basically you are suggesting I spend double the amount of time on it! I am already putting myself in trouble often putting 15-20 hours a week on it. There are times where I would have no problem putting that into a hobby project but not so much right now (the peek of availability for hobby projects is being salaried / with savings and being single. I'm not salaried I have little savings and I'm not single!). Just so many things adds up, answering support (here or via e-mail), lots or decisions to take, small or architectural, keeping the thing optimised and relatively sane. Like every software project most features that appears simple or minimal always end up taking three times the amount of work (lots of thing would be much easier working in a vacuum but here I can't just break everyone's code all the time).

I also fully agree that the better visuals will attract more people. I feel that strongly and I keep hearing comments about the visuals. I will work on visuals (and I am) but the library needs to grow at controlled pace to contain the influx of requests and desire from extra users. If the library looked beautiful one year ago I would have had a hard time to make the changes I needed to make during the year. People would have looked at it and be disappointed. It would have lacked features and I would have had to break it every three weeks. I need to get the features stable to build the visuals upon them. Better visuals are planned but several things needs to be sorted out before. If I just rush into visuals right now it would jeopardize a lot of other factors.

Then I think people under-estimate the tight correlation between layout features and performance and visuals there is. The mockup in #184 is cool but basically break a million assumptions and techniques used by the code. So many little things about the design where chosen based on implementation or performance and as you try to make the design tweakable you have to tackle each of them. ImGui is sitting in a tight equilibrium that's also the reason it's so simple and small.

I need to protect 1/ ease of use and 2/ performances.
It's important in that process that we don't lose the quick & dirty usage possibilities of the library. On Tearaway or Dreams or WiLD they both have dozens of tools created by different people. They are mostly adhoc and a bit clunky but all extremely useful and ever evolving and a core part of the day to day development process. If you make the library look super neat it has side-effects on building interfaces. e.g. if your interface uses nice icons everywhere then suddenly you may feel like you can't add a button right now because you don't have the icon for it. So it's important to still allow for a programmer to quickly add an ugly unaligned button here and here for the sake of productivity and not be dragged away in visual considerations. I need to allow for both worlds to cohabits.

0. Imgui needs a website that should at least contain latest up to date downloads, donations links, cool shots/video, roadmaps, who's using it etc.

All of that is already on the github page in one way or another. Yes, it should be presented better and a web page would help but again it is lots of extra work to present things.

1. You may be under-estimating the power of this library,

I think it shines more as an embedded game-development library to create ten clunky-looking-tools a day rather than to create precisely designed and layed out tools. The former was lacking a solution and I think ImGui full-fills some of that. The later has already many solutions available (even if they all have their unique issues).

I think it's great that you and others e.g. ProDBG are using the library for things it wasn't meant to target initially, but the more I go this way of trying to emulate desktop apps, the more requests and features will come. It's way far off what most people expect of an UI library like QT for desktop apps. The possibilities are endless here and I could be spending an eternity full-fulling them. So I'm torn between appreciating that those uses are helping to push the library forward, and the fact that they are putting an infinite load of extra work on me :)

3. Ask for money on specific features. Less Patreon and more Kickstarter. Something along the line of: "Feature proposal XYZ: Create the TextEditCheckboxMultiline Widget" - Target: 500$

I think you are over-estimating the user base here.

• First I don't think anybody currently using ImGui would have put $500 on line for me to add a features like the multi-line text editor.
• Even if they did it would not have paid for my time if we are considering a programmer rate (but I am happy to be flexible with that) .
• Even ignoring the cost new features are the easiest to sell and market but the majority of the time is doing maintenance, support, optimisations, tweaking, architectural decision, documentation. And those are invisible and even harder to sell. The way a traditional company would handle that if they would inflate the cost of the feature (so the $500 above become $1500) to cover all the side things that need to be done.
• Finally, unless it really took off a commercially stable project backed by companies, I don't think it would be super healthy to aggressively try to monetize features and make this github a giant feature market. I'm sort happy to serve hobbyist and independent developers and the general interest. Yes I would implement any feature paid for (none so far) but I don't want to be waiting for an eventual fund to get moving and add things that people want. I think it'd be hard to juggle both systems together.

6. Create wrappers for other languages like C# so that people can use it in Unity or other cool engines from webgl/javascript via emscripten!.

Btw I added a link to Extrawurst' c-api from the readme. I am a bit torn again here because ImGui API was designed closely for c++ and without default parameter and function overloading a lot of it gets really confusing or tedious. I don't think ImGui would make as much sense in other ecosystem like .net or webgl.

Again none of the ideas are bad but they are all essentially asking for me to "spend more time on it" so I don't know what to take away from that. I will look into setting up a roadmap.

AA and better font support are probably close so those will give a bit of a lift.

[adamdmoss]

Personally I approve of any steps that omar wishes to take to avoid having imgui become a great burden or a chore - that would be the worst thing for everyone. I think having a slowdown date is a good idea.

[unpacklo]

You've done a fantastic job so far and the progress made over the last ~1 year has been pretty amazing! I've told you a few times before, but I need to say it again:

Thank you very much for all the hard work you've put into this and putting this thing out into the wild for people to use! ImGui really has kind of saved my ass when it comes to working on my game. It was a constant struggle of how to get things to be interactable and iterated on in the engine. My only tool before was completely text based console + hacked together "UI" which amounted to in game debug draws and hardcoded input handling... not pretty and very time consuming, but ImGui changed everything for me.

It's a little disappointing to hear that you haven't been able to quite make this thing a full-time gig, but I still have hope that you can slowly build more momentum and maybe you'll be able to dedicate more time to it later.

Have you thought about having a few maintainers to help you out with stuff? Maybe not implementation-wise (seems like ImGui is not yet mature enough to have a bunch of people writing code to trunk) but at least to help out with checking/categorizing issues and responding to newcomers who have basic questions?

I think it shines more as an embedded game-development library to create ten clunky-looking-tools a day rather than to create precisely designed and layed out tools. The former was lacking a solution and I think ImGui full-fills some of that. The later has already many solutions available (even if they all have their unique issues).

This is commandment number one of ImGui for me! I use ImGui to help me get things done, and I am willing to let things be quick and dirty now if it gets me to producing good work more quickly. No doubt, improved visuals are important and I think will hugely benefit ImGui in the future, but it should not lose sight of the fact that ImGui's power is to be a hammer.

[Pagghiu]

Omar, I really appreciate the time you've spent answering here.
I can see the reasons that are leading to your decisions and they seem very reasonable to me.
I still think that IMGUI (I see it more as a philosophy) could really become a competing product, but of course it needs some investment, as you're pointing out. I've been using many different UI systems in the last years in some real products and the amount of burden that where adding to develop and deploy even simple apps was unbelievable to me.

Qt SDK is several Gb (per platform), when you hit a bug you often have to wait for months before it gets fixed. If you want to fix-it (obeying the LGPL or buying the commercial license) and build it, good luck. They use all kind of DSL Languages (QML? JS? to work with C++?).
Deploying tools trying to track all needed .dlls and plugins are often out of date or not working (maydeployqt....aaaargh). And you end up with 30 mb of unneeded dlls for an hello world application.

I've gone through the path of making "web-apps", core in C# or C++ and UI in JS/HTML5...Endless hours trying to figure out different browser problems or this/that JS framework problems. And exposing everything as network service is not an easy task, nor very performant.

I've also used Xamarin for an older product, with a terrible resulting experience. They always look for the latest and greatest feature and they give very small priority to bugfixing. And of course bridging c++ and c# was a constant source of problems and inefficiencies. Maybe they will improve with the opensourcing of .net but hey, we're bringing an entire VM+runtime here so good luck with that.

With IMGUI I am able to add 1 .cpp file to my project (even 5 or 10 wouldn't be a problem) and I have 80% of what I had in all the other systems, still being multi-platform. And I know I can code/customise the remaining 20% (that I actually did something as you've seen).
The code is so small and concise that I can fully understand it and customise it to single pixel.

I cannot do anything with any of the other systems, as I would need one week just to understand how to BUILD them, let alone make a modification :)

The problem with existing UI Systems is that they try to be much more (from string handling to File IO/networking, xml, json oh my..) and in the end they lock you inside their system that you cannot leave in any way without throwing away a lot of written code.
My choice was to internally develop over the years backend code for everything not GUI using some small, self contained and single purpose open source library (mainly LibUV and some other single file libraries like stb, miniz/zlib etc.). IMGUI is perfectly orthogonal to this philosophy and closes the circle to create a complete software product.

In my opinion the only way to survive in a world where every couple of months a new platform arises to keep your UI and Backend code completely separated, always being able to replace the first.
Many bigger companies (Microsoft with Office, Dropbox with their product) are doing the same, but they rewrite the UI for each specific platform for optimal user experience.
For most of my company projects this is not necessary (for now) so IMGUI is a really great solution.

My 2 cents, I'm sorry to be maybe a little off-topic, I should probably write a blog post to express my thoughts on this large topic, rather than polluting this github issue ;)

I will try to show what I am doing (I will be porting some other projects to IMGUI soon) and continuing to share my experiences here, so that they can be helpful.

Thanks again for all you hard work.

[tamaskenez]

I just want to second @Pagghiu's opinion about the importance of the cross-platformness of ImGui.

I have yet to actually use ImGui but the sole reason I'm considering it is that it provides a nice, cross-platform GUI solution from WinCE to MacOSX.

About the features: for the outsiders this imgui-movement is generally known as some quick&dirty thing to put up some buttons and labels. I was surprised to see how far it has been developed. I could even write an email client in ImGui.

[ocornut]

Thanks for the kind words everyone. Yeah, portability is the major benefit and requirement that got me started. I started ImGui for the PS Vita and then on to PS4 and needless to say none of the supposedly "portable" solutions like QT are remotely able to run on those platforms.

I was always into writing "live" tools. My first game for the DS had a decent live editor PC-side ( https://www.youtube.com/watch?v=MS9kqrGt_bM ), we used QT only for a few things (most of the code was related to the OpenGL view) but even for that QT was a problem when we tried to get very dynamic widgets, and it forced callbacks and state sync everywhere. I remember being stuck with a particular version of QT because after upgrading everything would run very slow which was hard to believe. Probably did something wrong but it's always hard to know what. Anyway.

[ocornut]

@Pagghiu I've tweeted a bit of your message, seems like it resonate with people
https://twitter.com/ocornut/status/629792897328529408/photo/1

I'm still cautious because I think people are expecting too much of ImGui. It's still pretty much a "I don't care so much about layout" type of libraries and there's limitations coming with that. But I'm happy it can be helpful and inspiring to many. (and that I can use it myself =)

[Pagghiu]

Great tweet!

Regarding the layout as in imgui you basically define stuff in a "functional" fashion it's always easy to write dependant expressions that size something depending on previous stuff...90% of general desktop gui patterns can be implemented this way, and for the remaining 10% well, you can simply go with absolute coordinates (SetScreenCursorPos etc., I've done it in a couple of places).

I think that's the greatest thing about open sourcing something...someone will always try to hack your code and do the things you couldn't imagine!

[ocornut]

Today ImGui 1.0 is 1 year old, yippee!
kthxbye!

[emoon]

Thanks for all the hard work :)

[brucelane]

joyeux anniversaire ImGui !

[dumblob]

Kiitos paljon! Many thanks for being the first one making open-source widely available immediate mode GUI library usable even for more complicated scenarios than just quick'n dirty printout!

[phicore]

You can be proud of what has been acomplished in this 365 days.

We only can hope for even more stunning features. Thanks Omar

[jarikomppa]

Sorry to beat a dead horse, but to my ears, "Imgui needs a [...]" sounds
like someone is volunteering..

On Tue, Aug 11, 2015 at 3:41 PM, phicore [email protected] wrote:

You can be proud of what has been acomplished in this 365 days.

We only can hope for even more stunning features. Thanks Omar

—
Reply to this email directly or view it on GitHub
#259 (comment).

[ocornut]

Probably of not much use to anyone but that's the tool I'm using to create screenshot.
You can select windows to include, it adds a border, and allows you to finely resize windows for specific alignments. It also automatically include popups/menus.

https://github.com/ocornut/imgui/wiki/screenshot_tool

[ghost]

Any update about the C# version ?

[ocornut]

Any update about the C# version ?

Not happening AFAIK.

[extrawurst]

You could easily write bindings based on the c-api called 'cimgui'

On Friday, October 2, 2015, Scellow [email protected] wrote:

Any update about the C# version ?

—
Reply to this email directly or view it on GitHub
#259 (comment).

[dumblob]

Any update about the C# version ?

You could easily write bindings based on the c-api called 'cimgui'

Or use Zahnrad instead as it's pure C89.

[wizzard0]

@Scellow generating bindings for C# for cimgui works, cannot release now but can ensure you it works :)

[wizzard0]

@Scellow it's pretty easy to generate bindings for C# (from cimgui) with one of pinvoke generators, also probably you could wrap the imgui directly with SWIG or something other supporting C++

[ice1000]

(DONE!) Which means re-factoring the rendering data to be more future-proof. Switching to indexed rendering already broke rendering in the AA branch so it is the perfect time to do that transition. We should be able in the future to provide high-level information on windows so that virtual canvas, networked output is easier to work with. Also consider the possible transition to use a dynamic font atlas, perhaps the user would get e.g. a texture dirty-rectangle.

Can we get dirty rectangles in the viewport branch? Currently imgui is still full-screen re-rendered.

[ocornut]

Can we get dirty rectangles in the viewport branch? Currently imgui is still full-screen re-rendered.

No. What you are suggesting is 100% unrelated to the paragraph you quoted.

[ice1000]

No. What you are suggesting is 100% unrelated to the paragraph you quoted.

I was thinking about dynamic font atlas and dirty rectangles, I did a search and get

perhaps the user would get e.g. a texture dirty-rectangle.

This result so I quoted it. Maybe I've quoted too much.

[ice1000]

Does imgui currently support outputting dirty rectangles?

[ocornut]

You said above “currently imgui is still full-screen re-rendered.” which has nothing to do with using dirty rectangles to iteratively update the font atlas (which is not even supported yet), suggesting you misunderstood the problem.

While I am amenable to discuss many possibilities and improvements, it feels like that you are throwing out keywords around here without a strong case and understanding of their use case or underlying value. The last thing I need know are random work requests not coming from a realistic need.

[ocornut]

Does imgui currently support outputting dirty rectangles?

This question is ill-defined. You referred to two completely different things above so I don’t know what you are talking about anymore.

(The answer for both most likely cases is: no)

Instead of requesting hypothetical solutions to be implemented, please discuss your problem and what you are trying to solve.

[ice1000]

You said above “currently imgui is still full-screen re-rendered.” which has nothing to do with using dirty rectangles to iteratively update the font atlas (which is not even supported yet), suggesting you misunderstood the problem.

I wasn't clearly expressing my idea, sorry. I was talking about too many unrelated things at the same time so it looks misleading.

I'm currently using pure imgui with its example implementations (I used many backends and use CMake to manage them, like glfw+opengl, win32+dx11, apple metal, etc.) to create tiny UI, and I realized its GPU usage is very high (as expected). Also, I need to render many Unicode symbols.

I wonder if I can achieve:

0. partial render, to reduce unnecessary re-draws
1. dynamic font atlas, to prevent from creating too-large font atlas

I know there's a technique called dirty-rectangles, say, mark the rectangles that need to be re-rendered in each frame and only render those rectangles. This can achieve 0 above. I found this issue by search that word.
Dynamic font atlas is something else I want but I'm still digging the implementation of imgui's font related codes and I'm not expecting that very urgently.

[ocornut]

create tiny UI, and I realized it's taking a lot GPU.

Please back this with repro and numbers - because normally it shouldn’t take much GPU. If you have rounding and borders on item frames it is a little more expensive but shouldn’t be dramatic and there’s an ongoing PR that will eventually improve it (even if the main intent of that PR was not to improve GPU costs but mainly CPU costs).

Solving 0 and 1 above would require totally unrelated solutions, as they are two different probleme.

I think it is unlikely that we’d ever support a caching system at the level your wording suggest. Imgui may support variable frequency refresh on a per-window basis but what will be designed to lower CPU cost. When we add bounding box in each ImDrawCmd the user might technically hash the contents of each draw command and perform some kind of caching and reusing of previous imgui render-target, but that seems not very useful.

Dynamic font atlas is desirable and will be done, the difficulty of doing it right is not really related to requesting the back-end to refresh the texture.

[ice1000]

variable frequency refresh

Can you elaborate? How does "variable frequency" work? Do you mean by reducing refresh frequency if there's no user input?

[ocornut]

Some windows (eg: windows not focused/hovered) could preserve the last ImDrawList content and return false on Begin(), and only actually refresh every few frames. the load over multiple windows could be balanced over frames.

[ocornut]

Closing this old topic, no point is leaving it up! (many of ideas discussed in the first post are a reality or in the world, some are still threads to pursue).