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

[NostraMagister]

Version/Branch of Dear ImGui:
Version 1.90.6

Back-ends:
imgui_impl_sdl3.cpp + imgui_impl_vulkan.cpp

Compiler, OS:
Windows 10 + MSVC 2022

Full config/build information:
No response

Details:

I initially used ImGui 1.89.6 with SDL3 3.0.0 and Vulkan 1.3.250 for building a test application using the ImGui window system to display 4 simultaneous webcams (captured with FFmpeg) as textures. This included ImGui sub-windows inside the main SDL3 window to select web-cams and make some selections such as video display size. It worked 100% correctly.

I upgraded ImGui 1.89.6 to 1.90.6, SDL3 3.0.0 to 3.1.2 and Vulkan 1.3.250 to 1.3.283 and fixed the ABI changes.
Everything still works 100% correct EXCEPT that I have a problem with ImGui fonts loading. All text characters became white square blocks BUT they can still be used (e.g. clicked to select web-cams from a list box) and the code continues to work correctly and behave as expected. Vulkan can be removed from the trouble shooting because I ran the code after upgrading ONLY Vulkan and the fonts where still there. SDL3/ImGui had to be upgraded together due to ABI changes in both.

I ignored the following ImGui wiki comment and excluded its solutions as the possible problem because the default font loaded and worked fine before upgrading and I only use the default font. Hence there cannot be a size problem IMO.

(4) Font atlas texture fails to upload to GPU.

This is often of byproduct of point 3. If you have large number of glyphs or multiple fonts, the texture may become too big for your graphics API. The typical result of failing to upload a texture is if every glyph or everything appears as empty black or white rectangle. Mind the fact that some graphics drivers have texture size limitation. If you are building a PC application, mind the fact that your users may use hardware with lower limitations than yours.

After upgrading ImGui/SDL3/Vulkan, based on the following ImGui change log comment, I made some changes:

Backends: Vulkan: Removed parameter from ImGui_ImplVulkan_CreateFontsTexture(): backend now creates its own
command-buffer to upload fonts. Removed ImGui_ImplVulkan_DestroyFontUploadObjects() which is now unnecessary.
No need to call ImGui_ImplVulkan_CreateFontsTexture() as it is done automatically in ImGui_ImplVulkan_NewFrame().
You can call ImGui_ImplVulkan_CreateFontsTexture() manually if you need to reload the font atlas texture.
(#6943, #6715, #6327, #3743, #4618)

I had the following code below BEFORE the upgrade. The UploadVulkanFonts() method below was called WITHOUT first calling ImGui's io.Fonts->AddFontDefault() or io.Fonts->AddFontFromFileTTF(...) because as I said I only use the default font. I assumed that the default font was present in the ImGui Font Altas by default, which is confirmed in the wiki. So the following code worked perfectly WITHOUT any .ttf file in my project/directories.

// Upload Vulkan backend Fonts into the GPU
void MainWindow::UploadVulkanFonts()
{
VkResult err = VK_SUCCESS;

// Use any command queue and reset it so that we can start a new command buffer sequence
VkCommandPool command_pool=this->gui_MainWindowData.Frames[this->gui_MainWindowData.FrameIndex].CommandPool;
VkCommandBuffer command_buffer=this->gui_MainWindowData.Frames[this->gui_MainWindowData.FrameIndex].CommandBuffer;

Check_VkResult(vkResetCommandPool(this->sdl.vulkan.vul_Device, command_pool, 0));

// Start a new command buffer
VkCommandBufferBeginInfo begin_info = {};
begin_info.sType = VK_STRUCTURE_TYPE_COMMAND_BUFFER_BEGIN_INFO;
begin_info.flags |= VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT;
Check_VkResult(vkBeginCommandBuffer(command_buffer, &begin_info));

// Let ImGui add commands to the command buffer to create the font textures for loaded fonts.
ImGui_ImplVulkan_CreateFontsTexture(command_buffer);

// Finish the command buffer 
VkSubmitInfo end_info = {};
end_info.sType = VK_STRUCTURE_TYPE_SUBMIT_INFO;
end_info.commandBufferCount = 1;
end_info.pCommandBuffers = &command_buffer;
Check_VkResult(vkEndCommandBuffer(command_buffer));

// Submit the command buffer and wait until all commands were processed. So we are sure not 
// to start using fonts that are still being loaded to the GPU.
Check_VkResult(vkQueueSubmit(this->sdl.vulkan.vul_Queue, 1, &end_info, VK_NULL_HANDLE));
Check_VkResult(this->sdl.vulkan.DeviceWaitIdel());

// Let ImGui clean-up all objects/structures it used internally and that needed to exist while the command buffer
// was processed (because they were referenced in commands).
ImGui_ImplVulkan_DestroyFontUploadObjects();
}

After the upgrade, ImGui_ImplVulkan_CreateFontsTexture() does not need to be called anymore
according the change log and ImGui_ImplVulkan_DestroyFontUploadObjects() doesn't exist anymore.
As a consequence, the REST/REMAINDER of the above code makes no sense anymore because there is
nothing in the command_buffer anymore. Previously the command buffer was filled by ImGui through the
ImGui_ImplVulkan_CreateFontsTexture(command_buffer) call.

So I simply changed the above function with a no-op (and I eventually will remove the UploadVulkanFonts() completely):

void MainWindow::UploadVulkanFonts(){return;}

While everything else keeps working 100% the characters are white cubes. Although I didn't call ImGui's io.Fonts->AddFontDefault() BEFORE the upgrade, I added it to the code as part of trying to solve this problem. The function DOES return a font handle as expected but the white cubes remain. I do NEVER push/pop fonts anywhere in my code (not before and not after the upgrade) based on the wiki examples that show that when one does NOT push/pop the default font is always used. So I still don't have any .ttf file in my project.

I assumed, based on the change log sited above, that ImGui_ImplVulkan_NewFrame() would load the default font automatically and I seem to remember that this default font is imbedded in the ImGui code or header files.

On a personal note, as far as I understood, this approach of automatically loading the fonts in ImGui_ImplVulkan_NewFrame() was discussed in an SDL2 context. Could it be that some extra implementation is needed to make this work with SDL3 too?

I have explored everything I could (I think) and posted this first in the discussion, but I have made an issue from it after re-reading the wiki Fonts page and running out of solutions to try to solve this myself.

Thanks for any reaction.

[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.

[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.

[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.

[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.

[Raven33]

Hi, I have the same problem, white rectangles instead of the characters.
I can confirm that it comes from ImGui, as the issue occurs when I upgraded from 1.90.2 to 1.90.9.
It seems to have to do with DynamicRendering, as the only change I had to make to upgrade was going from:

initInfo.ColorAttachmentFormat = (VkFormat)swapchainImage.format;
ImGui_ImplVulkan_Init(&initInfo, VK_NULL_HANDLE);

To:

initInfo.PipelineRenderingCreateInfo = pipelineRenderingCreateInfo;
ImGui_ImplVulkan_Init(&initInfo);

Note that I have validation running and there are no errors returned by the layers.
I downgraded, do not need to update now.
I just wanted to add my own experience to the discussion.

[NostraMagister]

@Raven33
Thanks.

This boils down to changelogs:

2024 - 02 - 14: *BREAKING CHANGE * : Moved RenderPass parameter from ImGui_ImplVulkan_Init() function to ImGui_ImplVulkan_InitInfo structure.Not required when using dynamic rendering.

2024 - 02 - 12: *BREAKING CHANGE * : Dynamic rendering now require filling PipelineRenderingCreateInfo structure.

2023 - 07 - 04: Vulkan: Added optional support for VK_KHR_dynamic_rendering.User needs to set init_info->UseDynamicRendering = true and init_info->ColorAttachmentFormat.

While I was concentrated on:

2023-11-10: BREAKING CHANGE: Removed parameter from ImGui_ImplVulkan_CreateFontsTexture(): backend now creates its own command-buffer to upload fonts.
BREAKING CHANGE: Removed ImGui_ImplVulkan_DestroyFontUploadObjects() which is now unnecessary as we create and destroy those objects in the backend.
ImGui_ImplVulkan_CreateFontsTexture() is automatically called by NewFrame() the first time.
You can call ImGui_ImplVulkan_CreateFontsTexture() again to recreate the font atlas texture.
Added ImGui_ImplVulkan_DestroyFontsTexture() but you probably never need to call this.

This is useful info because I am replacing all backends (SDL3/Vulkan) implementation code by my own so that I can download ImGui Core alone. The entanglement of demo code and implementation backends is something I want gone and have a clean interface of what data must be made available to the ImGui core during the different stages. Once that code is running and if the white rectangles would still be there I'll make the same changes as you did.
Thanks again.

[Raven33]

@NostraMagister
To be very clear, this is not a fix, I simply downgraded back to 1.90.2.
As I did not need to upgrade and have not had the time to debug this.
I will investigate on my end, but for now I still live in 1.90.2 land.

[Itachi546]

I fixed this issue by providing proper color format in PipelineRenderingCreateInfo.

[NostraMagister]

Thanks.

…

On Wed, Dec 4, 2024 at 8:06 AM Itachi546 ***@***.***> wrote: I fixed this issue by providing proper color format in PipelineRenderingCreateInfo. — Reply to this email directly, view it on GitHub <#7602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AM3IBXYQY4SO7HY6ZLQSZD32D2SXNAVCNFSM6AAAAABH5LU772VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJWGM3DMNBSGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>