Separating text capabilities from Dear ImGui

[Folling]

I've been using Dear ImGui on and off for about a year now. I think it's quite well known that one of the biggest missing features right now is sophisticated text support. As it stands right now Dear ImGui cannot be used for internationalised applications without an obscene amount of effort.
This is a shower-thought, so please don't mind if it's complete gibberish.

The things lacking at the moment are, as far as I'm aware:

• The lack of a dynamic font atlas
• The lack of right-left text support
• Potentially also the lack of some more sophisticated text features, like aligned wrapped text

To leverage these things I propose to separate the text handling mechanisms of Dear ImGui at some point in the future into a similar realm where the graphics-backend has been moved too.
This would allow users to already bind some more sophisticated graphics libraries like Pango/Cairo or Skia or something home-made into Dear ImGui - potentially leveraging maintenance overhead in the long run and as far as I'm aware allowing to drop the STB "dependency".

The idea would be not to move it into the existing backends as that would be cause for a lot of duplication but rather to treat text rendering as a completely individual set of operations. I'm not too familiar with the text rendering internals at the moment, but I could imagine that you would result in a usage along the lines of text_backend_get_index_in_string(str, x_position)
which then needs to be filled in by the backend.

The current implementation could be used as a default for all examples to make sure that this is only a forwards facing breaking change for new beginners.

Of course it will also be a major breaking change for fully custom backends - assuming they don't want to make use of the then provided default implementation.

Do you reckon this would be an approach that could further or benefit Dear ImGui?

[ocornut]

I don't disagree with the fact those things are lacking but I think you are vastly underestimating the complexity of getting it right with the right perfs and overhead suitable for Dear ImGui operation, all the subtle interactions involved between such "text operation back-ends", the likely transition to needing to cache every text entry etc.

IHMO it's absolutely not the right approach to aim at using those high-level libraries and I'd rather put effort at supporting better text functions and dynamic font atlas in the core. It's not likely that full internationalization support with ever be in scope for Dear ImGui 1.x at it stands but there's lots of things we can improve.

So from my pov this is not something I'm going to experiment with but if you or someone wants to give it a try please do, I'm sure we'd be learning something from it.

[Folling]

I'm not sure if any caching would be needed at all. Cairo/Pango were just an example and the enduser would need to make that performance estimation themselves. Again - I'm not too familiar with how the internals work, but I am well aware of how complicated text handling is in GUI libraries - which is why I proposed this in the first place.
I fail to see how there would be any performance overhead however (beyond mere function calls) by placing certain text operations in an implementation-defined interface (see my text_backend_get_index example). But that might just be due to my lack of understanding.

I might give this a shot one of these days, though I first wanted to get some input on it - thanks!

[sgf]

I agree that imgui should render the text independently.
And should be exposed in the form of interfaces. imgui's current scenario is just an option.
Users should be able to implement other solutions more easily on their own.(only need implement the text render interface )

[sgf]

If imgui does not have the capacity or the resources to achieve a better solution,
then this piece should give developers more convenience.
For example, let them integrate the operating system with its own scenarios(win32:directwrite&d2d). Or let them do it themselves.

The official solution(imgui's text render) does not currently support multi-language simultaneous display. Even forcing multiple font loads consumes a lot of memory and does not support features such as text scaling.

[ocornut]

As mentioned, feel free to work on this if you'd like and then we can discuss it in this topic.

Otherwise this is just a wishful topic I'm not sure I know what to do with. (The same way, If someone showed up saying "let's rewrite a third of dear imgui!" I'm not sure what I can do about it.)