Performance improvement suggestion

[FlogramMatt]

Skipping filling out info about current version I'm using because this is a more general question/suggestion.

In this ticket:
#2268

You write this @ocornut :
Addendum: Your subject line says "re-render only on user interaction" but the point of the technique highlighted is in my first paragraph is mainly to avoid running the ImGui:: functions and touching your source data. The actual rendering cost is generally lesser than the building of it.

What I'm wondering is how hard would it be to add a flag that says don't rebuild this item or is there a way to skip rebuilding it? Seems like checking if anything has changed for an item or tracking changes and telling it to not rebuild the vertex buffers and command lists items that aren't touched would typically be much cheaper performance-wise than rebuilding and repainting the item every step. In particular, I'm working on creating my own Immediate Mode library for my own language that would ideally be a Dear ImGUI wrapper. It'd be fairly easy for me to take care of checking whether or not to redraw and what not as long as there was a way for me to tell Dear ImGUI not to do it.

I love imgui, and generally, believe it's generally worth the performance hit, but if you could be competitive on that front too.. would be wonderful and the best choice for writing a UI without question! Thanks for all the work you've put into it @ocornut :)

[ocornut]

Aside from solution such as #2749 (which we will adopt) one possibly way to easily implement a system like it is to alter/modify the refresh frequency at the window level, so given the right settings e.g. Begin() could return false on some windows and keep old vertices. At the finer widget-level I don't think it is worth the architectural change and would likely be both slower and more complex, but I think as a supplement to #2749 we will probably add some specialization for poke-based color change so a blinking cursor would register its position in the vertex steam and we can alter its alpha.

[FlogramMatt]

@ocornut I agree that's a good idea but seems like as long as you are moving the mouse around, highest frame rate is needed. Maybe that's ok as it's only this application that would get that input. Multiple windows would only operate at the minimum frame rate.

I've debated building my own immediate mode gui library from scratch.. would take quite a while to get close in terms of features but could be useable fairly quickly. Seems like it could be done so that individual parts of the UI are updated only when either there is input or an alarm.

Could be that instead of comparing variables directly (strings, in particular, seem slow to compare), I keep track of individual variables being used by parts of the UI and flip a bool when they change. Only if they've changed do I repaint that little part of the UI. I'd prefer to change it in ImGUI if possible. And that part could simply be a textbox or a slider, not the entire window. A combo box closing would likely mean a whole screen refresh is needed. What do you think?

Probably should wrap imgui for the time being though until I have a product and hopefully donations or other revenue or more programmers contributing.

[rokups]

A great care is taken to keep things as fast as possible and UI performance is hardly ever an issue even in very complicated applications. Did you do any profiling to prove there is a performance problem? If UI is so slow that it requires caching of vertex data - i do not believe this caching will be of any help, as UI will probably be too slow on interaction. Only real benefit i can see is conserving power usage on mobile devices, however that is not exactly a target market for this library, therefore using imgui for mobile app would be an uphill fight simply because components are not designed with touch screens in mind.

[FlogramMatt]

Performance is good, I'm not complaining too much the demo with a number of open widgets takes only 2% to 3% CPU, on a fairly high-end computer and I believe this could be brought down to a 1/10th of this. And if this were to become a regularly used library with multiple apps using it at once.. this would add up quickly. Given this is the only advantage that retained-mode libraries have, seems like it'd be great to take it from them. Plus I'm working on my own programming language that could easily automate away this part if there are complexities.