Imgui: Flickering Bug with SplitChannel, / MergeChannels and DrawList->AddImage

[aiekick]

Version: .70 WIP (16990)
Branch: master

I have a weird flickering bug.

I use SplitChannel, / MergeChannels for have a style applied on a bg of a group

i have a pingpong texture displayed with drawlist->AddImage , so the id of the texture displayed change after each swap.
see in the gif, the flickering is due to the image display. when i mouse over the flickering stop

if i comment drawlist->AddImage, it work, when i uncomment, the next items are flckering.
not sure if its a bug of imgui or from my softs.

[ocornut]

Hello,
Could you try to make a minimal repro?
Thank you.

[aiekick]

ok, i will try.

[aiekick]

its difficult to do a small repro.

the problem appear only when i split channels, and only with my pingpong system.

each rendering of my texture, i swap the texture id. (back becone front and front become back of what its uploaded to the gpu)

after that i calc and render imgui.

i dont know how, but my texture is used by the next imgui item control. this is why its filickering.

i will inspect the split channel method

In fact, the filckkering stop when i add a text with drawList->AddText

[ocornut]

@aiekick Any news on this?
The point of a repro is to narrow down the issue. There's probably a bug in the channel splitter but it would help if you tried to made a repro. It doesn't look hard, and I can't be guessing what your code is doing.

EDIT I am pretty confident your double-buffer system has nothing to do with it, as ImDrawList won't see any of that on a given frame.

[aiekick]

i know what is the goal of that. but i have tried to do a small repro but i not got the bug. i thinck i have a gl context bug since start of NoodlesPlate dev, and maybe some memory leaks somwhere but nout found where (because i see sometime the font texture in place of my textures.
the problem occur when i switch the texture id, but liake said not found a bug with a minimal case. i will search more, maybe is near the texture binding, when i fill one..

[aiekick]

finally succeed to isolate the problem. i have created a repo with a fully workable example : https://github.com/aiekick/ImGui_DrawList_ChannelsSplitter_Bug
use the GLFW Opengl3 sample and try
you were right, my double buffured system is not the problem, but a texture creation before the loop.. its weird

[aiekick]

i found, that if i intialize my texture after your (for the font), it work like a charm.
we see the font texture in each framed group and all texts.

is there a possibility than using a texture number other than 1 for the font (the first texture is the font i thinkc), can cause a bug somewhere ? i know we can have more font so more texture numlber, but the frist font is always 1 no ?, if his initialization in done first of all.

[aiekick]

i have remove my texture creation and,

in ImGui_ImplOpenGL3_CreateFontsTexture()

i have duplicated the line "glGenTextures(1, &g_FontTexture);"

like that i ensure than the first texture number will be 2 instead of 1. the bug is appearing

no texts under ImGui::Images

[aiekick]

i thinck the bug is in ImDrawListSplitter::Merge(ImDrawList* draw_list)

at last if i always do AddDrawCmd instead of UpdateClipRect,=> no bug.
maybe we need to do UpdateTextureID() after UpdateClipRect no ? it resolve the bug too
maybe in some case he can add two drawcalls. not sure if its possible and/or normal :) so maybe we can don a function who group these two's

in my case UpdateClipRect not trigger a drawcall.
but the UpdateTextureID yes :)
can we have UpdateClipRect and UpdateTextureID both triggering a drawcall both ?

in layered imgui,
when i use only ImGui::Image (whti different id than font) and some AddLine, AddRect after => bug
if i use ImGui::Image and ImGui::text => no bug

can't help more i thinck :)

i have modify imgui in my app code, for have the UpdateTextureID after the UpdateClipRect . and there is no more bug now :)

[ocornut]

I would like to get this fixed but it is still extremely tedious to wade through the noise of an entire repo and so many messages, for what should be a 10 lines repro...

[aiekick]

i know but it was not easy to found the bug. im not an expert in dev..
for summary i have added "draw_list->UpdateTextureID();" after the " draw_list->UpdateClipRect();" in ImDrawListSplitter::Merge(ImDrawList* draw_list)

[ocornut]

All I have asked is for a minimal repro (instead of large project) in order to understand the bug.
Here I made it now:

// Confirm hard-coded values 0x01 (atlas) and 0x02 (empty) do what we expect with our OpenGL back-end
{
    ImGui::Text("1:");
    ImGui::SameLine();
    ImGui::Image((ImTextureID)1, ImVec2(50, 50));   // Confirming this is our atlas
    ImGui::SameLine();
    ImGui::Text("2:");
    ImGui::SameLine();
    ImGui::Image((ImTextureID)2, ImVec2(50, 50));   // Confirming this is showing as black
}

// Bug repro
{
    ImDrawList* draw_list = ImGui::GetWindowDrawList();
    draw_list->ChannelsSplit(2);
    draw_list->ChannelsSetCurrent(0);
    ImGui::Text("Hello");
    draw_list->ChannelsSetCurrent(1);
    ImGui::Image((ImTextureID)2, ImVec2(50, 50));
    draw_list->ChannelsMerge();
}

[ocornut]

Now I have the repro I can understand and fix the bug, should be fixed now.
I understand you had found the fix before, but you never let me understand the issue. I cannot apply the fix if I don't understand the issue. This is why the minimal repro is required.

Thanks for reporting!

[aiekick]

i have created a project here :https://github.com/aiekick/ImGui_DrawList_ChannelsSplitter_Bug ..
it was a full repro of the bug. its easy now after some iterations but it was not before that

[ocornut]

Lots of noise (unnecessary code to understand) in this entire repository, the minimal repro I postes above is 7 lines, it can’t get simpler.

Thanks for finding this!