Fonts become white rectangles after upgrading to most recent ImGui/SDL3/Vulkan versions about imgui

[NostraMagister]

@ocornut
Thank You.

It is indeed strange. While I wrote the previous post, and returning to RenderDoc the display auto-updated and it now shows the characters, as if there is some sort of latency. I was not under the impression that RenderDoc did something of its own when you don't click/use one of its features manually. Yet the swapchain image number 130 didn't change.

So I capture a new one and its the white cubes again.
I reselect the first captured frame again and ... its the white cubes again while the left side pane shows the characters (in very small). And I just took a look and it changed to characters again.

Yet, everything keeps running and ImGui controls are responsive.

And still I will go to the bottom of this :) Thanks for your reply.

[NostraMagister]

@PathogenDavid
Thank you for your advice.

I think a race condition or comparable synchronization problem could be the case. With ImGui 1.89.6 everything worked and after upgrading to 1.90.6 with only 8 lines of code changes to fix ABI changes (see OP) the problem suddenly occurred. Yet, I traced the ImGui and my code and everything returns exactly what one would expect. As I said everything keeps running perfectly, even interaction with the ImGui controls or data in list boxes. Just the characters become white cubes.

By following omar's advice to use RenderDoc, several other possible causes are excluded such as that the default font would be damaged or that I did something in my old code (where i provided the Vulkan command buffer) that is no longer done now that NewFrame() takes automatically care of font loading (a good improvement because if one uses only the default font one doesn't need to do anything anymore). If the default font appears when RenderDoc is starting my program, then all code lines needed to display proper characters must still have been present in my application after the upgrade of the 8 lines.

So what remains are some race condition as you suggested or some other synchronization problem. NewFrame() is called in the event loop, while in 1.89.6 I explicitly loaded the default font BEFORE the main event loop started.

ImGui only uses Device, Queue, QueueFamily, Allocator and MinAllocationSize set by my code to load the Fonts with its own command buffer, and hence I am sure that the font is loaded on the same 'device' and that a graphical queue is used (which both are required for these fonts to work).

Possibly, RenderDoc, by activating its layer may either cause a latency somewhere that, unwantedly, fixes the problem, or prevents a race condition just by some small time or sequence shift.
Anyways, I want my code to run like clock-work and I'll investigate until I have a solutions because letting this kind of things uninvestigated and unexplained is asking for trouble in the future where it will surface at the most inconvenient moment.

Thanks again for your suggestions.

[ocornut]

Thanks for researching this and writing down detailed info.
I don't think SDL2 vs SDL3 would make a difference here, nor the Vulkan version.
I would say it is likely a bug in your code but might as well be a bug in our Vulkan backend.

It's hard to say what's wrong, tho I only had time to skim your issue. I think you could step in the debugger into ImGui_ImplVulkan_NewFrame() and perhaps use a graphics debugger such as RenderDoc. Try to confirm if the texture itself is correct in memory (it could be that the texture is incorrect vs it could be that it's not correctly bound or rendered).

You might want to update to Nov 9 version of imgui repo, confirm that it works, then update to Nov 15 version, that to confirm that it is this precise change that affected you.

[ocornut]

(I tweaked subject line and adding link to #7595 here just in case, but I believe all the info are already in this thread)

[NostraMagister]

Thank you for the reply.

For clarity the following:

If my OP lead to believe that it was specifically the upgrade to ImGui Version 1.90.6 that (possibly) introduced this problem, then I need to emphasize that I cannot know that. I noticed it with Version 1.90.6 after upgrading from ImGui 1.89.6. So I have no solid ground to claim that it was introduced by version 1.90.6. It might have been already there in an older ImGui version after 1.89.6 or not at all be an ImGui problem and be in my code. If I find what it is then it will be easy to find from what version it came.

If it is in my code I only changed 8 lines to fix ABI changes (ImGui/SDL3), merely 2 related to fonts, with this upgrade and all are code remarks of function arguments that no longer exist or functions that are not needed anymore or also no longer exist. I will revisit them all again to be sure.

I will investigate AddFontDefault() for starters because it returns a font handle (as mentioned in OP), which if there were problems with finding the font to add it to the Font Atlas it would probably not return an handle. Next I will look into ImGui_ImplVulkan_NewFrame() as you suggested. I figure the default font is loaded there on the first pass that notices a font in the atlas has not been loaded yet. I can then see if all Vulkan variables that are used to load the command buffer to the GPU are correctly set and if there are could be sync. problems. This code sequence should be quite comparable to the Vulkan code I posted in OP.

The big ImGui concept difference between the mentioned ImGui versions is that:
Before, when one loaded the fonts textures themselves, fonts were traditionally loaded before the main loop started. With the new ImGui approach where ImGui loads the fonts in ImGui_ImplVulkan_NewFrame() they are loaded during the main loop. In my code they are then in competition with other asynchronous Vulkan code threads that load the camera textures in the Vulkan buffers (for performance reasons). Maybe ImGui_ImplVulkan_NewFrame() can therefore not load the font command buffer due to some device availability or synchronization problem.

I will look further into all this and communicate results here if I find something.
Thank you for your help.

[ocornut]

I will investigate AddFontDefault() for starters because it returns a font handle

I don't think you need to investigate this. The core Dear ImGui side of things in terms of fonts won't have any issue especially as you are not calling particular font function. At the time of calling AddFontDefault() or Build(), there are no interactions with the graphics system. The issue is either in the backend either in your interaction with the backend or vulkan, and lies in the texture upload or binding.

Again my suggestion are:

• Use RenderDoc to inspect the texture data or texture calls.
• Trying to narrow dear imgui versions a little bit would be helpful.

[NostraMagister]

Intermediate update.

Trying to narrow dear imgui versions a little bit would be helpful.

ImGui version 1.90 is the first to have it, all the way up to 1.90.6. I didn't test early 1.90.7 and non of the 1.89 versions above 1.89.6 because the ABI changes (ImGui and SDL3) don't allow me to go back.

I continue to investigate, but I think the problem is not in either the ImGui or my code.

Rather then erroneous code i think it is the concept change of a command queue imbedded in NewFrame(), and hence font loading in the main loop rather then before the main loop started, that specifically for Vulkan users will require some implementation changes related to proper synchronization. For now this is a working hypothesis.

Hence, this requires application redesign but no ImGui work. I will confirm if I get there.

[NostraMagister]

Intermediate Update II

If I start my program with RenderDoc the problem of the characters becoming white cubes doesn't occur anymore and everything is normal. If I start the program through the command line again the white cubes are back. All this without changing anything and without any code rebuilds. It is consistent, a starting method always results in either working or not working.

At least this proves that the default Font data is not corrupted. It also proves that using the 'default' font does NOT need any coding since 1.90.(0-6) and is automatically available as documented in the changelog through vulkan NewFrame() calling ImGui_ImplVulkan_CreateFontsTexture().

It is also clear that RenderDoc in someway does something that allows the ImGui code to find and load the default Font correctly. I don't use vulkan layers but renderdoc registers its layer. I cannot imagine that makes the difference.

Next Step: I will check environment variables and dig deeper because I want to understand why this is happening after an ABI upgrade (ImGui & SDL3) of about 8 lines that should in no way have changed anything as show in OP.

[GamingMinds-DanielC]

If I start my program with RenderDoc the problem of the characters becoming white cubes doesn't occur anymore and everything is normal. If I start the program through the command line again the white cubes are back.

Did you set up command line parameters and working directory for launching from RenderDoc as well? If there is a discrepancy and the code handles not finding some files by reverting to defaults, that might explain a different behavior.

[NostraMagister]

@GamingMinds-DanielC
Thank you for your reaction.

In a normal run i don't have any command line parameters. I position in the exe directory with Windows CMD then start it.

With RenderDoc I give it the same path and exe as the one I positioned in with CMD. The working directory (filled in automatically by render doc) points to the same directory where the exe is. So, I guess I have identical working directories.

What I just discovered is that while starting with RenderDoc the characters show properly in my application, capturing a frame and analyzing it with RenderDoc's Texture Viewer shows the white cubes again and no characters. The captured image by RenderDoc is a B8G8R8A8_UNORM coming from the swapchain (swapchain Image).

So I see BOTH now, my application showing a correct display with characters and apparently a swapchain image in RenderDoc with the white cubes which is identical to what I see in my application when I do not start it with RenderDoc.

NOTE: RenderDoc is new to me.

[ocornut]

Seems like you are hitting quite a fringe situation. It may be that RenderDoc is interested in your case: I would assume that ideally the software aims to have zero side-effects, and in situation where it's not possible or practical for it to have zero side-effects, they probably know/understand what those cases are and it may be possible to get a hint by asking there.

[PathogenDavid]

I don't use vulkan layers

It'd be a good idea to check them, you might have some subtly invalid API usage somewhere. (Even outside of this situation you should really develop with debug layers enabled.)

I would assume that ideally the software aims to have zero side-effects

Graphics debuggers generally don't attempt to handle most forms of invalid API usage, and RenderDoc is no exception.

It could also be that @NostraMagister has a race condition. (Either between multiple CPU threads or just between the CPU and GPU.) Graphics debuggers always impact timing of everything quite a bit.