Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for and implement window resizing #314

Open
drjaska opened this issue Jan 13, 2025 · 6 comments
Open

Allow for and implement window resizing #314

drjaska opened this issue Jan 13, 2025 · 6 comments

Comments

@drjaska
Copy link
Contributor

drjaska commented Jan 13, 2025

When the application is resized it doesn't behave ideally, and the current observable behaviour differs between Vulkan and OpenGL.


Vulkan

2025-01-13.01-34-16.mp4

When the window is resized vertically it does not recognise the resolution change. If the window is made smaller then the drawn pixels shift down and the bottom pixels are not drawn on screen anymore.

When the window's resolution is cut in half horizontally then Vulkan just crashes.

Crash log
^3vk_present_frame(): restarting swapchain...
...presentation modes: FIFO FIFO_RELAXED IMMEDIATE
...selected presentation mode: IMMEDIATE, image count: 3
^3vk_present_frame(): restarting swapchain...
...presentation modes: FIFO FIFO_RELAXED IMMEDIATE
...selected presentation mode: IMMEDIATE, image count: 3
^3Vulkan: vkWaitForfences returned VK_ERROR_DEVICE_LOST^3Vulkan: vkWaitForfences returned VK_ERROR_DEVICE_LOST----- Client Shutdown (Server fatal crashed: Vulkan: qvkQueueSubmit( vk.queue, 1, &submit_info, vk.cmd->rendering_finished_fence ) returned VK_ERROR_DEVICE_LOST) -----
Closing SDL audio playback device...
SDL audio playback device closed.
SDL audio shut down.
RE_Shutdown( 3 )
----- Client Shutdown (recursive error after: Vulkan: qvkQueueSubmit( vk.queue, 1, &submit_info, vk.cmd->rendering_finished_fence ) returned VK_ERROR_DEVICE_LOST) -----
WARNING: Recursive CL_Shutdown()
Sys_Error: recursive error after: Vulkan: qvkQueueSubmit( vk.queue, 1, &submit_info, vk.cmd->rendering_finished_fence ) returned VK_ERROR_DEVICE_LOST

OpenGL

The window resizing is not recognised here either but it doesn't crash. When the window is made smaller it doesn't shift where it draws making it seem like all other windows are drawn on top of it

2025-01-13.01-35-13.mp4

I tested this on X11 with a patched dwm as a Window Manager. Same behaviour on Debian and Arch.

I don't know if these are related to X11, Wayland or every operating system which allows resizing the window size of fullscreen applications without making it not fullscreen but windowed.


I also attempted r_fullscreen 0 and then resizing the window but it doesn't want to change its size at all.

@ec-
Copy link
Owner

ec- commented Jan 13, 2025

It is not supposed to be resized at all: on windows it is blocked by corresponding bits, linux/x11/WMs may ignore desired behavior and even do not notify window about changed position/size so I see no way to fix this on non-windows platforms

@ensiform
Copy link
Contributor

ensiform commented Jan 14, 2025

The only way to do it is force a vid_restart for mod compatibility after the resize is finished. Might as well drop raw x11 support and only do SDL on non windows which has window resize event tracking

@drjaska
Copy link
Contributor Author

drjaska commented Jan 14, 2025

I'm sorry if this sounds harsh and I understand that software development takes a lot of time and effort but in my opinion disallowing window resizing is a dirty hack to kind of solve issues related to ignorance of situations where the window will resize. The proper action to take would be to actually handle window resizing.

and even do not notify window about changed position/size

At least on X11 if I open up xev on a screen and toggle fake fullscreening of another window on the same monitor I get the following event log.

xev log

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityPartiallyObscured

Expose event, serial 32, synthetic NO, window 0x5600001,
    (958,0), width 962, height 1080, count 0

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,0), width 960, height 1078,
    border_width 1, above 0xa0000d, override NO

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityUnobscured

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,0), width 960, height 10, count 3

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,10), width 10, height 58, count 2

Expose event, serial 32, synthetic NO, window 0x5600001,
    (68,10), width 892, height 58, count 1

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,68), width 960, height 1010, count 0

ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,0), width 960, height 1078,
    border_width 1, above 0x0, override NO

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityPartiallyObscured

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,21), width 960, height 1057,
    border_width 1, above 0xa0000d, override NO

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityUnobscured

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,0), width 960, height 10, count 3

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,10), width 10, height 58, count 2

Expose event, serial 32, synthetic NO, window 0x5600001,
    (68,10), width 892, height 58, count 1

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,68), width 960, height 989, count 0

ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,21), width 960, height 1057,
    border_width 1, above 0x0, override NO

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityFullyObscured

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,21), width 1920, height 1059,
    border_width 0, above 0xa0000d, override NO

ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,21), width 1920, height 1059,
    border_width 0, above 0x0, override NO

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,0), width 1920, height 1080,
    border_width 0, above 0xa0000d, override NO

ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,0), width 1920, height 1080,
    border_width 0, above 0x0, override NO

TL;DR: There are X11 ConfigureNotify events.

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,21), width 960, height 1057,
    border_width 1, above 0xa0000d, override NO
ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,0), width 1920, height 1080,
    border_width 0, above 0x0, override NO

Might as well drop raw X11 support and only do SDL on non-Windows

This is another option to consider.

@drjaska drjaska changed the title Window resizing issues Allow for and implement window resizing Jan 14, 2025
@drjaska
Copy link
Contributor Author

drjaska commented Jan 14, 2025

If Windows implementation is currently the best out of the supported platforms does it support resizing the whole desktop area and the window with it? In scenarios such as setting a 4k monitor down to 1080p while quake3e is running.

@ensiform
Copy link
Contributor

ensiform commented Jan 14, 2025

I'm sorry if this sounds harsh and I understand that software development takes a lot of time and effort but in my opinion disallowing window resizing is a dirty hack to kind of solve issues related to ignorance of situations where the window will resize. The proper action to take would be to actually handle window resizing.

and even do not notify window about changed position/size

At least on X11 if I open up xev on a screen and toggle fake fullscreening of another window on the same monitor I get the following event log.

xev log

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityPartiallyObscured

Expose event, serial 32, synthetic NO, window 0x5600001,
    (958,0), width 962, height 1080, count 0

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,0), width 960, height 1078,
    border_width 1, above 0xa0000d, override NO

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityUnobscured

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,0), width 960, height 10, count 3

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,10), width 10, height 58, count 2

Expose event, serial 32, synthetic NO, window 0x5600001,
    (68,10), width 892, height 58, count 1

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,68), width 960, height 1010, count 0

ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,0), width 960, height 1078,
    border_width 1, above 0x0, override NO

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityPartiallyObscured

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,21), width 960, height 1057,
    border_width 1, above 0xa0000d, override NO

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityUnobscured

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,0), width 960, height 10, count 3

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,10), width 10, height 58, count 2

Expose event, serial 32, synthetic NO, window 0x5600001,
    (68,10), width 892, height 58, count 1

Expose event, serial 32, synthetic NO, window 0x5600001,
    (0,68), width 960, height 989, count 0

ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,21), width 960, height 1057,
    border_width 1, above 0x0, override NO

VisibilityNotify event, serial 32, synthetic NO, window 0x5600001,
    state VisibilityFullyObscured

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,21), width 1920, height 1059,
    border_width 0, above 0xa0000d, override NO

ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,21), width 1920, height 1059,
    border_width 0, above 0x0, override NO

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,0), width 1920, height 1080,
    border_width 0, above 0xa0000d, override NO

ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,0), width 1920, height 1080,
    border_width 0, above 0x0, override NO

TL;DR: There are X11 ConfigureNotify events.

ConfigureNotify event, serial 32, synthetic NO, window 0x5600001,
    event 0x5600001, window 0x5600001, (4078,21), width 960, height 1057,
    border_width 1, above 0xa0000d, override NO
ConfigureNotify event, serial 32, synthetic YES, window 0x5600001,
    event 0x5600001, window 0x5600001, (3120,0), width 1920, height 1080,
    border_width 0, above 0x0, override NO

Might as well drop raw X11 support and only do SDL on non-Windows

This is another option to consider.

Even still, restarting the whole game backend is required. Mod code has no idea about the resize until the qvm or dll is reloaded. Hence why resizing doesn't look correct. It is not a hack but a limitation put in place by the existing game code API.

@drjaska
Copy link
Contributor Author

drjaska commented Jan 14, 2025

Okay, so window resizing will never be a completely smooth experience, but even if vid_restart is effectively done for each resize it would be far better than just straight up crashing on Vulkan or having most of the view be out of the window's area.

I think that ideally the view could be resized at any time but after X amount of time since a resize the window should (perhaps opt-out optionally to see what breaks?) vid_restart so that mode code can sync up. This would also make it so that drag resizing looks smooth (though with potentially warped assets before a vid_restart) and after the resizing is done and rendering is restarted the experience should be back to normal, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants