-
Notifications
You must be signed in to change notification settings - Fork 545
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clipping is not related to the window with the latest imgui #205
Comments
After further testing it turned it the workaround with uncommenting the line doesn't work when Suspend/Resume is used. nodes.Suspend();
c.igBeginTooltip();
c.igTextUnformatted(text, null);
c.igEndTooltip();
nodes.Resume(); See how the appearing tooltip brings back the issue: app_ASilm6ugow.mp4 |
Got a similar issue. Uncommenting the second line will bring back the canvas into the docked window space. However, my popup does appear in some other coordinate system and doesn't bring back the window background. |
I updated from 1.89.1, I think? to latest in order to debug some suspend/resume issues and got hit by this instead. Interestingly, the workaround seems to work great when the node editor window is docked. It only fails calling Suspend/Resume when undocked. |
I reviewed the diff between tags
|
Given the dependency between docking and the workaround, is it possible this is an upstream bug? @ocornut have you seen this before? |
Those commits are related to the ImGuiListClipper which seems to have nothing to do with this. This is not my codebase so hard to say, first you would need to do a proper git bisect to find the commit that changed the behavior and then we can figure out if this is a dear imgui behavior change/bug or a bug in the node editor code. Also try to open Metrics->DrawList and inspect the data here to see if there's a correlation. |
I tried to rebase the stack-layout imgui/, checked out imgui-node-editor/develop, updated the copy with latest rebased imgui + stack-layout (with few fixes pushed to #208) and couldn't see an issue. Please actually provide details as to how to reproduce the issue in |
@azonenberg @rtryan98 I welcome you to make a SSCCEE to reproduce that issue, as stated above. As this is not critical for me to update imgui right now, I am not pursuing it in the following days. |
@Namek Does updating ImGui solved the issue for you? |
Just checked with latest imgui from git and the issue is still present. |
This is a workaround for thedmd#205 pthom/imgui_bundle#117 Adding a simple pixel at m_WidgetRect.Max is enough to bypass the issue
@Namek I created a minimal reproducible example in this repository This code is self-contained in a short file: node_clipping_issue.cpp However it was not possible to use the ImGui version inside node editor, since it is outdated, and adds stack layout patches to ImGui which are not trivial to rebase. So it uses HelloImGui, which is based on a quite recent version of the ImGui docking branch. |
@ocornut you asked for a reproducible example, please see the comment above. @pthom thank you. I tried to downgrade imgui to the version that I was using when it worked (1.88) which is commit 81160fee56027226bc80b48e196d0332f5541a8c from the docking branch (listed here https://github.com/ocornut/imgui/commits/docking?after=f8704cd085c4347f835c21dc12a3951924143872+664&branch=docking&qualified_name=refs%2Fheads%2Fdocking). However, helloimgui gets in the way as it's incompatible with it. I think it would be best to find which commit of imgui actually broke the editor. The workaround doesn't work for me. It changes things but not to better. |
Took me 30 mins to figure out how to build and run this but since pthom made the effort to make it I went ahead. I don't see any issue and or maybe don't know what to look for. |
Bonjour @ocornut :-) , hi @thedmd and @Namek
I'm sorry it took you so long to build the example. I think it was an error on my side to use a third party such as HelloImGui. I rewrote the minimal repro repository so that it uses only ImGui, imgui-node-editor and SDL (and nothing else). This demo is able to trigger different subtle issues that arise when using docked windows, and/or windows whose size is unknown at the first frame (so that the canvas does not know its size) They are detailed in the Readme. Also, I made a short video in order to demonstrate them, as well as the use of the repo (in the hope to make it easier to setup). I think the video is a good way to get a more complete picture of the issue. thanks Note: I can confirm that the issue seems to be absent with ImGui docking v1.88 (commit 58eb40db76783f5da09e592ca3eb421f4f2197e3). I'm not sure if that helps, though. Anyhow, I created a branch imgui_1_88 in the repository. It uses the SDL2 branch of SDL (you will need to remove |
The issue thedmd/imgui-node-editor#205 was absent with ImGui 1.88. Not sure if that helps, though
Sorry I would have been more explicit with it (and I appreciate/admire your thorough help and patience here): the bulk of my problems came from the fact that I'm running a PC i'm using less often for development, and even though I have five millions copies of git.exe and cmake.exe scattered in various installation directories, it took me a while to find a shell where I could access I'm cloning the new stuff now and will look into it. |
The first thing was to add a call to Here I could notice that when the bug appear, the Here you can see the ClipRect is (0,0)...(1264,672) when it should be the similar as the draw command below it (not exactly same as there's some padding involved). Although I don't know imgui-node-editor codebase, I know that thedmd is well acquainted with advanced details of ImDrawList and may be inclined to pull some neat low-level use, which either could reveal a bug in imgui, either could easily break if some underlying logic changes. I changed your workaround to use If I grep for |
The issue started happening in an imgui update between 1.89.1 and 1.89.2, specifically between Nov 24 and Dec 1. |
If I comment the contents of // Pop trailing draw command (used before merging or presenting to user)
// Note that this leaves the ImDrawList in a state unfit for further commands, as most code assume that CmdBuffer.Size > 0 && CmdBuffer.back().UserCallback == NULL
void ImDrawList::_PopUnusedDrawCmd()
{
#if 0
while (CmdBuffer.Size > 0)
{
ImDrawCmd* curr_cmd = &CmdBuffer.Data[CmdBuffer.Size - 1];
if (curr_cmd->ElemCount != 0 || curr_cmd->UserCallback != NULL)
return;// break;
CmdBuffer.pop_back();
}
#endif
} So I add a dynamic breakpoint: void ImDrawList::_PopUnusedDrawCmd()
{
#if 1
while (CmdBuffer.Size > 0)
{
ImDrawCmd* curr_cmd = &CmdBuffer.Data[CmdBuffer.Size - 1];
if (curr_cmd->ElemCount != 0 || curr_cmd->UserCallback != NULL)
return;// break;
if (ImGui::GetIO().KeyShift)
printf("breakpoint\n"); // set breakpoint here
CmdBuffer.pop_back();
}
#endif
} Get myself into the situation where the bug appears and press SHIFT to trigger the breakpoint. I noticed that 2 empty commands are popped during the
|
I'll need to let @thedmd finish this investigation, but I looked at iteration into # if IMGUI_EX_CANVAS_DEFERED()
m_Ranges.resize(m_Ranges.Size + 1);
m_CurrentRange = &m_Ranges.back();
m_CurrentRange->BeginComandIndex = ImMax(m_DrawList->CmdBuffer.Size - 1, 0);
m_CurrentRange->BeginVertexIndex = m_DrawList->_VtxCurrentIdx + ImVtxOffsetRef(m_DrawList);
# endif
m_DrawListCommadBufferSize = ImMax(m_DrawList->CmdBuffer.Size - 1, 0);
m_DrawListStartVertexIndex = m_DrawList->_VtxCurrentIdx + ImVtxOffsetRef(m_DrawList); Since the value is set multiple times every frame, to visualize I use this neat trick: ImGui::Begin("DEBUG");
ImGui::Text("m_DrawListCommadBufferSize = %d", m_DrawListCommadBufferSize);
ImGui::End(); Creating and appending into a window declared locally inside that function. When the bug appears a third line appears: I suspect changing FIx should be applied from |
@omar |
It wasn't a corruption in the "memory stomping" sense, neither a ImDrawCmd merging issue, simply it looks like the first drawcmd cliprect is not properly transformed because that computation for |
Thank you @ocornut for taking a time to investigate. I appreciate that. You're correct. Canvas did made some assumption about how ImGui deal with ImDrawCmd. If I can recall correctly there was always an empty one ready in the buffer. I will investigate the issue. |
@ocornut : (the part below is only for info if you want to give HelloImGui a try) In order to develop quick and dirty tests on the ImGui docking branch you could do this (by default they will use glfw as a backend).
mkdir external
cd external
git clone -b docking https://github.com/ocornut/imgui.git # any version on the docking branch should work
git clone -b master https://github.com/pthom/hello_imgui.git
cd ..
cmake_minimum_required(VERSION 3.12)
project(hello)
set(CMAKE_CXX_STANDARD 17)
# Add ImGui & HelloImGui
# i. tell HelloImGui to use our own version of Dear ImGui in external/imgui/
set(HELLOIMGUI_IMGUI_SOURCE_DIR "${CMAKE_CURRENT_LIST_DIR}/external/imgui")
add_subdirectory(external/hello_imgui)
# ii. Make `hello_imgui_add_app` available
list(APPEND CMAKE_MODULE_PATH ${HELLOIMGUI_CMAKE_PATH})
include(hello_imgui_add_app)
# Build your app
hello_imgui_add_app(hello_world hello_world.main.cpp)
target_link_libraries(hello_world PRIVATE hello_imgui)
#include "hello_imgui/hello_imgui.h"
#include "imgui.h"
void Gui()
{
ImGui::Text("Hello, world!");
}
int main(int, char **)
{
HelloImGui::Run(
Gui,
"Hello!",
true // window_size_auto
// Uncomment the next line to restore window position and size from previous run
// , true // windowRestorePreviousGeometry
);
return 0;
} |
… sentinel callback // Patch for imgui-node-editor, which sometimes leaves // its sentinel callback ImDrawCallback_ImCanvas on the command list // (ImDrawCallback_ImCanvas is actually -2 cast to ImDrawCallback // and thus, not a valid pointer, since it equals to 0xfffffffffffffffe // See issues: // thedmd/imgui-node-editor#282 // and thedmd/imgui-node-editor#205 // + partial solution: thedmd/imgui-node-editor@af7fa51 bool isUserCallbackAddressValid = ( reinterpret_cast<uintptr_t>(pcmd->UserCallback) < 0xffffffffffffff00 );
I have updated imgui from 1.88dock to 1.89.3dock. The screen is cut, depending on the position. It seems the editor has the size of the window but its clipping is not related to the window but rather to the world space (?).
The recording should explain what's going on, notice the huge black parts around the editor:
app_Gsf0CuRIrC.mp4
What's interesting though, I've found this code in the
imgui_canvas.cpp
:I have uncommented the last line and it seems to fix everything (it is, remove the black parts and not crop the content):
However, it doesn't seem to be a proper fix since it is commented as debug code.
The text was updated successfully, but these errors were encountered: