Comments (15)
@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.
from imgui.
@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.
from imgui.
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.
from imgui.
(I tweaked subject line and adding link to #7595 here just in case, but I believe all the info are already in this thread)
from imgui.
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.
from imgui.
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.
from imgui.
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.
from imgui.
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.
from imgui.
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.
from imgui.
@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.
from imgui.
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.
from imgui.
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.
from imgui.
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.
from imgui.
@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.
from imgui.
@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.
from imgui.
Related Issues (20)
- PlotLines() doesn't register its ID, does not work with SetItemKeyOwner() HOT 1
- Recording ImGui Vulkan command buffers offline
- Table angled headers, sorting only works on first column HOT 11
- Interact with the game/app when the ImGui is collapsed. How can i do that? HOT 1
- CalcWorkRectSize discrepancy HOT 1
- Find window with focus when main menu used HOT 6
- AddFontFromFileTTF HOT 2
- Item-tooltip for text will disappear for a short time the text get resized HOT 1
- The use of two newFrame() caused ImGui_implWin32_WndFrocHandler to fail
- How do I create a modifiable table? HOT 1
- Regarding opening of two frames, which caused ImGui_implWin32_WndFrocHandler to be unable to accept messages HOT 6
- DockBuilder is overriden by imgui.ini for a new window HOT 4
- SDL: focused viewport pushed into the background by tooltips in its own viewport
- Semi transparent background (Win32, DX11) HOT 5
- "Getting Started" guide misleading step HOT 1
- Suggestion: Extend demo with full screen window / docking examples HOT 9
- Set default tab in TabBar HOT 1
- Suggestion: Add a TabItem that behaves like a Button HOT 3
- Gallery: Post your screenshots / code here (PART 20) HOT 3
- feat: API for Styling glyphs HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from imgui.