Window size == 0 - How to handle properly?

[PowerOfNames]

Hey :)

've been digging through the windows.cpp example code and common/entry/entry_windows.cpp; common/entry/entry.h and entry.cpp but seem to be overlooking something.

When my glfw window is minimized or x/y are set to 0, I get a crash.

Following case:

• multiple windows are supported
• each is "managed" as view
• each view contains multiple framebuffers with potentially multiple textures/images.

The problem is definitely in my code, but after trying for a while now, I struggle to find the cause. The only example that seems to tackle window related framebuffer resizing seems to be the windows.cpp example and I followed that but there is not code that guards againts x || y being resized to zero.

I also checked the headless example, because there framebuffer resizing happens, but there the fb is created with size only, not with custom attachments.

I was wondering how bgfx handles any dimension being 0 (or minimized windows).

Technically, every time a window resize happens, you want to get rid off of the old framebuffer and its attachments (and all render targets, really) and create new ones with the new size, except if one dimension is zero.

This is what crashes atm. As I said, the issue is definitely in my code, but i would be nice so get some additional information here. It seems that bgfx detects if a window was minimized and just does nothing than?

Thanks :)

PS: I use the vulkan backend exclusivels, which does not allow x or y to be 0 in its swapchain or during image creation.
I am unable to find where this print comes from through:

"BGFX Clamped swapchain resolution from 1600x1 to 1600x0"

The renderer_vk.cpp SwapchainVK::update() function does clamp, but does not produce any prints.
Its also not the swapchain that crashes but one of my images.

The whole output for that resize event:

[11:59:01602] BGFX WARN Invalid frame buffer dimensions (width 1600, height 0).

[11:59:01602] Viewport(2)::RemakeBgfxHandlesOfFrame_RT 0
[11:59:01602] Viewport(2)::RemakeBgfxHandlesOfFrame_RT 1
[11:59:01603] BGFX Creating vkTexture with exportable mem: 0

[11:59:01603] BGFX Texture   5: RGBA8 (requested: RGBA8), 1600x31x1 RT[x], BO[ ], CW[ ].

[11:59:01604] BGFX Creating vkTexture with exportable mem: 0

[11:59:01604] BGFX Texture   4: D32F (requested: D32F), 1600x31x1 RT[x], BO[x], CW[ ].

[11:59:01606] BGFX Clamped swapchain resolution from 1600x1 to 1600x0

[11:59:01611] BGFX ---E-             Unknown, Validation, 0: vkCreateSwapchainKHR(): pCreateInfo->imageExtent (width = 1600, height = 0) is invalid.
The Vulkan spec states: imageExtent members width and height must both be non-zero (https://docs.vulkan.org/spec/latest/chapters/VK_KHR_surface/wsi.html#VUID-VkSwapchainCreateInfoKHR-imageExtent-01689)

[11:59:01623] BGFX Create swapchain numSwapChainImages 2, minImageCount 2, BX_COUNTOF(m_backBufferColorImage) 10

[11:59:01623] BGFX Successfully created swapchain (1600x0) with 2 images.

[11:59:01624] BGFX ---E-             Unknown, Validation, 0: vkCreateImage(): pCreateInfo->extent.height is zero.
The Vulkan spec states: extent.height must be greater than 0 (https://docs.vulkan.org/spec/latest/chapters/resources.html#VUID-VkImageCreateInfo-extent-00945)

If this clamping always happens when one of the dimension is 1, I can deal with it easily.
Currently I only check for 0, which seems to be the issue, as a resize to 1 is not caught by the engine but bgfx clamps it down? Not entirely sure what happens here

[PowerOfNames]

Edit:

I dug deeper into bgfx' renderer_vk.cpp code and found this codeblock inside bgfx::vk::SwapChainVK::createSwapChain():

		if (TextureFormat::Count == m_colorFormat)
		{
			BX_TRACE("Create swapchain error: Unable to find surface format (srgb: %d).", srgb);
			return VK_ERROR_INITIALIZATION_FAILED;
		}

		const VkFormat surfaceFormat = srgb
			? s_textureFormat[m_colorFormat].m_fmtSrgb
			: s_textureFormat[m_colorFormat].m_fmt
			;

		const uint32_t width = bx::clamp<uint32_t>(
			  m_resolution.width
			, surfaceCapabilities.minImageExtent.width
			, surfaceCapabilities.maxImageExtent.width
			);
		const uint32_t height = bx::clamp<uint32_t>(
			  m_resolution.height
			, surfaceCapabilities.minImageExtent.height
			, surfaceCapabilities.maxImageExtent.height
			);
		if (width != m_resolution.width || height != m_resolution.height)
		{
			BX_TRACE("Clamped swapchain resolution from %dx%d to %dx%d"
					, m_resolution.width
					, m_resolution.height
					, width
					, height
					);
		}
		```
		
		this is essentially what causes the problem. And I am not sure what the goal of this code is.
		Reading the vk docs, the minImageExtent is always less then or equal to the currentExtent field, except for when that is a special value.
		The issue here is, that this does not seem to be a constant value. What happens now is for example, that if I want to resize to height = 2, the minImageExtent,height ends up being 0 (for some reason current extent is 0 0 at that point already) so my 2 gets clamped to be 0, rendering the whole swapchain invalid. However, it still tried to do createAttachments further down the line, which ultimately crashes because its forbidden in Vk to create images with either x or y being 0.
		
		My assumption is, that glfw's window is resized to something small, or even hits zero in one tick, and the next it is positive again, leading VkSurfaceCapabilitiesKHR.currentExtent containing the old value still, but the renderer wants to resize to another larger value.
		
		Could it be that bgfx nowadays wraps resizing logic away for windows?
		I also wonder how headless should be tackled now.