Imgui: View IDs for BGFX compatibility

[OswaldHurlem]

BGFX contains a modified version of ImGui which is used by some of its example code. In this version, ImGui's style stack is modified to have a ViewId field, which is then noted in each ImDrawCmd.

https://github.com/OswaldHurlem/imgui/pull/1/files
(EDIT: These changes were written by me based on BGFX's mod of ImGui)

BGFX can then use the ViewId in each ImDrawCmd. In BGFX draw calls must be submitted with a particular ViewId for bucketing. Not sure exactly how this works but it's documented in API Reference->Views here: https://bkaradzic.github.io/bgfx/bgfx.html

This seems a bit Procrustean and I suspect there's a better way to inject this information into ImGui's returned instructions, without modifying ImGui's source.

Thoughts?

[ocornut]

Well I don't know how this works and how exactly bgfx needs it, so the initial problem has to be stated before we can consider a solution. I wouldn't merge the PR you linked as-is, but I'm open to finding a solution.

If I look at bgfx source code I only find one reference to this:
https://github.com/bkaradzic/bgfx/blob/e74a5d784325c2f92eb0deae836f770dd57e1677/examples/common/imgui/imgui.cpp#L412

ImGui::NewFrame();
ImGui::PushStyleVar(ImGuiStyleVar_ViewId, (float)_viewId);

And skimming through that code it doesn't seem very useful anymore (or at least not in a way that couldn't be replaced by a variable on bgfx side). @bkaradzic ?

[OswaldHurlem]

I wasn't proposing that those changes be merged.

(Also, I should note that what I linked are my changes, not the exact ones from BGFX. I used the latest ImGui then copied BGFX changes, surrounded with an ifdef.)

Perhaps ImGui can provide a way to put generic user data in it's draw list? Could be analogous to how people use the Tag in Windows Forms to treat certain controls just a little differently.

[OswaldHurlem]

Suppose I had a custom ImGui control (eg RenderKanji(...)), and I wanted to push a style parameter which is useful for that control but not to any of ImGui's builtins (eg bool KanjiRendersVertically). How would I do that, currently?

Maybe that's out of scope.

[ocornut]

Perhaps ImGui can provide a way to put generic user data in it's draw list?

Will add a raw ImVector<char> vector to push user data, to ease the use of callbacks (you can already pretty much do everything with callbacks, but the vectors will make some uses easier as you don't need to push the data in your own buffer, which would be more tedious to setup when dealing with multiple draw lists).

However as I recall the ViewId thing with bgfx had (at least at the time) a specific reason why it needed to be done this way. I don't remember it, maybe that reason doesn't exist anymore as Branimir in the other thread just mentioned maybe none of this is useful anymore?

"ViewId was added there when I supported multiple windows + ImGui (not supported anymore the same way as before). In bgfx swap chain is treated just as visible frame buffer."

Suppose I had a custom ImGui control (eg RenderKanji()), and I wanted to push a style parameter which is useful for that control but not to any of ImGui's builtins (eg bool KanjiRendersVertically). How would I do that, currently?

You could have your own parameeters / settings / globals / stack, since they are your own controls.

[bkaradzic]

I just removed it from my fork:
https://github.com/bkaradzic/imgui/commit/7bde4189134942f40a56bb224e4d9b10dd98296d

It was used for multiple window support to pass ViewId that represents window. In bgfx order of submission doesn't matter, so it's possible to interleave submission of multiple widgets for multiple windows together.

ImGui::Text("Window #1");
PushStyle(ViewId, otherWindowId);
ImGui::Text("Window #2");
PopStyle(1);

Code like above would render these two UI elements in different windows (depending on View setup).

Also View setup in bgfx can happen at the end of the frame...

[ocornut]

Interesting, thanks for the clarification.
That example is particularly surprising/unexpected because you're switching ViewId (so presumably OS window) between two text draw calls but the vertex positions would still be dictated by imgui-level positions.

The viewport branch will provide similar functionality at a different level, so when this stabilize in a month or two we could figure out how it would work out with bgfx.

(Ideally the imgui viewport binding design would allow either the existing windowing+rendering framework to handle the rendering, either the windowing+rendering of the secondary imgui windows could be completely be handled by the default per-platform binding. So _in theory_ even if bgfx completely ditched multiple windows, users could plug in the Win32+DX11 code (regardless of what BGFX) use and have secondary imgui viewports uses that. In practice I expect issues but hey we can dream. I know of at least one game project that used to run native Win32+DX11 on one side and GLFW+OpenGL on the secondary viewport, so why not)

Closing this now.

[bkaradzic]

That example is particularly surprising/unexpected because you're switching ViewId (so presumably OS window) between two text draw calls but the vertex positions would still be dictated by imgui-level positions.

It was intended as illustration, not really use case. But way how it worked was push style and then set window position, etc.