Blank ImGui menus/Menus not updating correctly when opened
Describe the bug
Seemingly for no reason some menus can open with text being rendered far enough up from the "window' that it isn't visible at all, or only partially visible. All of these cases affect all ImGui selection lists (butchering, activate, dragging etc). No clear way of reproducing the issue. Pressing any key causes for the list to update and render correctly.
Attach save file
Steps to reproduce
- Open any ImGui menu
- Hope that the issue shows itself
Expected behavior
Menus should render properly. I think, dunno, maybe...?
Screenshots
Versions and configuration
- OS: Windows
- OS Version: 10.0.19045.4651 (22H2)
- Game Version: cdda-experimental-2024-08-16-0646 0b8d7ba [64-bit]
- Graphics Version: Tiles
- Game Language: System language []
- Mods loaded: [ Dark Days Ahead [dda], Magiclysm [magiclysm], Disable NPC Needs [no_npc_food], Portal Storms Ignore NPCs [personal_portal_storms], Slowdown Fungal Growth [no_fungal_growth], SpeedyDex [speedydex], Stats Through Kills [stats_through_kills], Bombastic Perks [bombastic_perks], Work in Progress Limb Stuff [limb_wip], Translate Complex Dialogue [translate_dialogue], Pixel's Various Fuckery [Pix's Shit] ]
Additional context
No response
I'm having the same issue, the world loading menu is always a black blank screen, so is the magiclysm spell menu and the container pocket settings. I think it's related to screen opacity and/or screen nested levels
The loading screen is a separate problem, already filed as #75678
Since I cannot reproduce this problem, could someone who can reproduce it try out my branch at https://github.com/db48x/Cataclysm-DDA/tree/uilist-alternate-mouse-handling to see if the problem goes away?
cdda-windows-tiles-x64-2024-08-26-1250
Steps to reproduce
Use only keyboard (did not test with mouse)
- open the debug menu
spawning- spawn a
vehicle - press
esc - open any menu (main/debug menu)
- get the "black" menu
- press
esc - open the menu and get the "normal" version
I get it 10 out of 10 times.
Those steps to reproduce don’t do anything special for me. I open the vehicle spawn menu, then close it, then open any other menu and the other menu is still perfectly fine.
Clarification. The position of the scrollbar is important.
I hope the video will play. https://github.com/user-attachments/assets/c94e527f-3d8e-4620-966f-b6dee8a13afd
I'm not sure if I translated it correctly. Apparently, the scrollbar position is saved between different windows.
Ok, that’s something concrete to go on. Except that ImGui doesn’t work that way. We don't save scrollbar positions.
Maybe it's important? I took a screenshot and played around with it a bit.
- The background (image of the main window?) is visible through the window. The assumption is that the focus stays on the past window instead of moving to the new one? After all, after interacting with that window, the background is no longer visible.
A more illustrative example. After opening a window and after interacting with this window.
- You can notice a scrollbar on the right side of the window. And also that all the items have gone beyond the upper border of the
menudebug window. It's rather strange for a window where all the items fit into the visible area. The scrollbar should not appear there at all.
There is a faint transparency in the default ImGui theme, which we are currently using unmodified (but see #75699). That transparency results in the background getting darker because we don't actually clear the screen between frame. That’s kinda dumb but it was done in the name of efficiency.
But it’s a red herring because only one ImGui window is actually present at any given time here. First the main menu is opened, and an item selected. That closes the menu and opens another. You can see in the video that a keyboard navigation in the vehicle spawn menu apparently causes the previous menu to be scrolled when it is reopened. But because they are separate objects, and only one is active at a time, that doesn’t make sense.
The uilist does scroll the current menu item into view if needed, but it also highlights it. In the video the second time the main menu is opened the highlighted menu item is scrolled off the top of the window. It hasn’t been scrolled into view, it has been scrolled out of view! So it cannot be that you navigated to the 10th item in the vehicle menu and then it scrolls the 10th item into view on the main menu. Not only would the 10th item be selected in that case, it still shouldn’t cause the main menu to be scrolled, because the 10th item would fit in the available space.
ImGui does have some state that holds the scroll offset of each active window, in pixels. But if that were being shared between these two windows then it wouldn't cause this bug either, because the scroll offset was zero pixels in the vehicle menu!
It really doesn’t make sense either way.