Open Kozakow opened 1 month ago
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)
s
pawningv
ehicleesc
esc
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.
A more illustrative example. After opening a window and after interacting with this window.
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.
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
Fort Motte-trimmed.tar.gz
Steps to reproduce
Expected behavior
Menus should render properly. _I think, dunno, maybe...?_
Screenshots
Versions and configuration
Additional context
No response