From 93a71120d43b35d18ec16af4706f0c3e8abc713e Mon Sep 17 00:00:00 2001 From: Ivor Wanders Date: Sat, 9 Aug 2025 08:12:22 -0400 Subject: [PATCH] fix: Initialise splash window with correct size (#2390) With an initial Window size of 1 by 1, the program aborts during launch on my Debian 12 (bookworm) system running the Mate Desktop environment on X11. The exception from X is the following: ``` $ ./imhex [18:36:33] [INFO] [main | Main] Welcome to ImHex 1.38.0.WIP! [18:36:33] [INFO] [main | Main] Compiled using commit master@59c6d30 [18:36:33] [INFO] [main | Main] Running on Linux 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) (x86_64) [18:36:33] [INFO] [main | Main] Linux distribution: Debian GNU/Linux 12 (bookworm). Version: 12 X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0x5400009 Serial number of failed request: 152 Current serial number in output stream: 163 ``` The culprit is in `hex::init::WindowSplash::initGLFW()`, specifically the `glfwCreateWindow` call with a window size of 1 by 1, that's the last call in the ImHex codebase, after that it's libglfw and libX11. The issue can be worked around by inhibiting the splash screen using the `IMHEX_SKIP_SPLASH_SCREEN=1` environment variable, setting the window to be a size larger than 1 by 1 also seems to resolve the situation. My hunch is that an underflow occurs somewhere with the smaller values, but I did no further investigation into analysing the root cause. ---- Above the line is the commit message. ### Problem description See https://github.com/WerWolv/ImHex/issues/2215, which I think is the same problem, and commit description above. Edit; I did another search in the issues, I wouldn't be surprised if #2233 is a duplicate of the 2215 issue. ### Implementation description Please see the commit message. Analysis was done by setting an X11 error handler, making that throw and running it in a debugger. This is available in this dev commit; 4a24e16a2ef100a9417e572f6b16c4a95711e94e. ### Screenshots No apparent glitches if I make the splash window stick around with `return std::nullopt;` in the `loop()` function. I don't know if there's an issue at the beginning, but given that the window is set to transparent before it is created and resized I don't expect any. Here's a compulsory screenshot of the splash screen over an editor; image ### Additional things > Anything else you would like to say Yes! I don't use ImHex often, but it's really useful when I do, thank you! --- main/gui/source/init/splash_window.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/main/gui/source/init/splash_window.cpp b/main/gui/source/init/splash_window.cpp index dfc5cfa50..27aecb4bf 100644 --- a/main/gui/source/init/splash_window.cpp +++ b/main/gui/source/init/splash_window.cpp @@ -470,7 +470,7 @@ namespace hex::init { glfwWindowHint(GLFW_CLIENT_API, GLFW_OPENGL_API); // Create the splash screen window - m_window = glfwCreateWindow(1, 1, "Starting ImHex...", nullptr, nullptr); + m_window = glfwCreateWindow(WindowSize.x, WindowSize.y, "Starting ImHex...", nullptr, nullptr); if (m_window == nullptr) { hex::nativeErrorMessage(fmt::format( "Failed to create GLFW window: [{}] {}.\n"