Ability to render Dear ImGui in a specific region

[deadlocklogic]

Basically I am using IMGUI as a secondary GUI kit and I am trying to embed it in my primary kit.
Is there a way to restrict IMGUI Window rendering to a specific region?
Thanks for this great library.

[GamingMinds-DanielC]

Sure there's a way. You will need to implement custom backends to transform your inputs to ImGui and to render its outputs. ImGui just gives you a vertex buffer, an index buffer and information about draw calls it generates. Whether you render those with appropriate transformations directly into your backbuffer or into a texture first that you then draw by other means is entirely up to you. Take a look at the sources of the backends (system and renderer) that you are most familiar with and use them as a reference.

[ocornut]

You can alter io.DisplaySize after running the platform backend's NewFrame function, and you might need to reimplement the rendering backend's Render function to alter Viewport setting accordingly.

Various other reasons (easier/standardized DPI framebuffer scale support, remapping of absolute multi-viewports coordinates to be positive) are likely to lead us toward backend supporting some form of inputs coordinate transforms, so it's not impossible we would support this out of the box in the future.

[deadlocklogic]

Thanks.
I think this feature is immensely beneficial/flexible.

Basically I could tinker in the backend to be able to draw in a specific region, and I can delegate transform inputs too.
Need to hack around drawing widgets with a borderless fixed ImGui Window.

Making this kind of features built-in without extra effort/customization would bring more modularity to this library.

[deadlocklogic]

@ocornut Is there any roadmap, milestone list about this?
I understand that you put bug fixes/minor improvements first, which is essential for a popular/stable library.
And I am aware that this library is being used in production, other than just debugging purposes.
I have a few suggestions. the first could be subjective but might help more contributors joining in:
1- Project structure: separate the single header file into more descriptive files which will help contributing way more than the current project structure, you can then write a script which will generate a single header file like most single header library do.
2- Introduce a unit system like android for example (px, dp, sp) units, you can implement this as overloads to current functions while using px as the default unit to keep backward compatibility (with deprecation/migration options for future releases).
3- Introduce the concept of a embedded windows: a frameless window which is bound by user defined constraints.
Thanks again.

[ocornut]

There are not roadmap/milestones for publicly requested features, I don't have the bandwidth to guarantee anything.

1- Seems like a bad idea leading to tooling issues/mistakes when working/debugging/hacking/patching/merging the lib. I also absolutely don't need more casual/tourist contributors. I need focused/experienced contributors. All source files are carefully indexed so you can jump around quickly with IDE features.
2- Most of render pipes needs rework for nice scaling and handling pixel alignment or non-alignment better, so this won't come before that. #6145 is also along those lines. We will introduce something but only when we have better out of the box support for scaling, which involve out of the box complete+partial texture update support in backends.
3- There are dozens of parameters influencing what this thing actually do and mean. This is what child windows are to some degrees. An upcoming BeginWorkRect api will probably be an alternative/intermediary solution to child windows for some cases.