Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Clipping error when using ImGui::SeparatorText in a node #214

Open
azonenberg opened this issue Mar 23, 2023 · 6 comments
Open

Clipping error when using ImGui::SeparatorText in a node #214

azonenberg opened this issue Mar 23, 2023 · 6 comments

Comments

@azonenberg
Copy link

Steps to reproduce: Call ImGui::SeparatorText() inside a graph node

Expected result: horizontal line stops at end of node
Actual result: line runs off to infinity at right side

I tried using a child window to do the clipping but this resulted in the node size growing to infinity.

Maybe related to #205?

separatortext

@thedmd
Copy link
Owner

thedmd commented May 2, 2023

Separators use windows WorkArea.Max.x to extend tehemselfs to whole window. On canvas this make little sense as there window is virtually infinite. At the moment there is no API that allow to modify WorkArea.Max.x. As a workaround you can include <imgui_internal.h>, set this value on current window to desired width and restore it after calling ImGui::SeparatorText(). Some widgets do not play nicely with scalling/canvas.

I think there is a workaround:
Judging by screenshot you posted, size of your node is known from the beginning. In this situation you can surround call to separator by ImGui::PushClipRect()/ImGui::PopClipRect().

Does that solve your problem?

@w0utert
Copy link

w0utert commented Jun 6, 2023

I have this same problem, and will probably try to work around this as suggested by @thedmd, but in my case nodes do not have a fixed size unfortunately. So this means I will probably have to somehow pre-calculate the node with based on the contents I'm going to put there.

I'm wondering whether it would be possible for imgui-node-editor to somehow calculate and set the clip rectangle automatically? I haven't studied the source code very well and I'm not an ImGui expert either, but I guess after calling ax::NodeEditor::EndNode, the size of the node is known, and could be used by subsequent draws to set the clip rectangle accordingly? For the first draw the clip rect could be set to (0, 0) so the first frame the node will be drawn empty, which may not be ideal but at least that way things like separators and collapsing headers can be used inside of nodes?

@w0utert
Copy link

w0utert commented Jun 7, 2023

I was able to implement the workaround suggested by @thedmd, by pre-calculating the width of the node header using that to set the clip rect for the rest of the node contents, that way separators etc are clipped correctly.

I did find another problem related to this though, which is sort of the opposite: if nodes move too far to the right, separators and collapsing headers are cut off too early.

For example look at the following screenshot where I disabled the PushClipRect workaround, so you would expect the separators to run all the way to far right end of the editor:

nodes

The orange node itself is drawn ok, but the separators are prematurely cut off.

Some observations:

  • If I zoom or pan the editor the cut-off coordinate zooms and pans along perfectly, as if it is part of the graph itself.
  • If I print the rightmost node coordinates they are very close to the width of the viewport of the window that holds the node editor.
  • If I move all nodes sufficiently far to the left, the clipping is not visible as it will be outside the window viewport.

I think what is going on, is that somewhere graph world-coordinates and window view-coordinates are being mixed up, affecting the WorkArea.Min/Max coordinates? The node-editor itself probably never looks at the window WorkArea so all its own drawing looks ok, but ImGui controls that use it are broken.

I don't know enough about ImGui internals though so maybe what I'm saying makes no sense. Is there no way for the node editor to make sure the window WorkArea coordinates are properly matched with the node editor zoom/pan transform?

@thedmd
Copy link
Owner

thedmd commented Jun 11, 2023

WorkArea is troublesome. To make things look right Node Editor would have to track much, much more state that now, basically immitate what child windows do. Editor will then became more susceptable to internal changes in ImGui which will bump maintainance time significantly.

I think the simplest way to address the issue is to roll out custom version of ImGui::SeparatorTextEx and edit const ImRect bb(pos, ImVec2(window->WorkRect.Max.x, pos.y + min_size.y));. I found no way around that otherwise.

Another option would be to patch local copy of ImGui with extension:

-void SeparatorTextEx(ImGuiID id, const char* label, const char* label_end, float extra_w);
+void SeparatorTextEx(ImGuiID id, const char* label, const char* label_end, float extra_w, float width = 0.0f);

Where width will be picked instead of value from WorkRect if width > 0. Depending on how useful it turn out to be it may became a PR for ImGui. : )

@w0utert
Copy link

w0utert commented Jan 26, 2024

Revisiting this for a new project that also uses imgui-node-editor.

@thedmd could you maybe have a look at Omar's comments on ocornut/imgui#7255 and comment on what he's suggesting (make imgui-node-editor WorkArea-aware and/or have a way to force node width so that controls like SeparatorText understand them)?

I would be willing to spend some effort trying to modify imgui-node-editor so it behaves better with controls that depend on WorkRect, but only if there is some chance this will actually work and would be considered for merging at some point. It would be really nice to be able to use not just separaters but for example also collapsing headers inside nodes.

@pthom
Copy link

pthom commented Sep 10, 2024

Also see #298 for a possible solution

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants