Add a workaround for a Windows NVIDIA Vulkan driver bug

[emezeske]

The NVIDIA Vulkan driver bug causes swap chains to be created with incorrect dimensions for native windows created with thread-specific DPI-awareness context.

This is a pretty subtle issue, and only affects processes where the process-wide DPI-awareness context is different from the thread-specific DPI-awareness context that was used to create a given native window. The Microsoft docs on this are pretty decent, and are super clear that the DPI-awareness of a HWND is whatever the DPI-awareness of the thread that created it was. The NVIDIA driver appears to be ignoring this. I suspect other drivers do as well.

This workaround has to be submitted into Filament itself because client code has no way to call a function on the Filament renderer thread, and so there's no way for a client to implement this workaround themselves.

I filed an upstream bug report with NVIDIA, but from what I can tell from other similar reports, they are not likely to fix the issue anytime soon.

Happy to answer any questions about this one; I know it's a bit hard to understand because it took me two days of beating my head against the wall to figure out myself. :D

(If you're curious why I am the first to see this, it's because my app is unusual in that it is a plugin that runs inside other applications. This is the exact kind of weird edge case that caused Microsoft to introduce the thread-specific DPI-awareness system, because the host application may have different DPI-awareness than the plugins it hosts.)

[emezeske]

By the way, I should mention that I did consider an alternate formulation of this workaround, which is to change the thread's DPI-awareness inside VulkanPlatformSurfaceSwapChain just prior to each call to vkGetPhysicalDeviceSurfaceCapabilitiesKHR().

This alternative has the advantage that it would support the extremely weird case that the calling application is binding swap chains to multiple native windows that were created with different DPI-awareness contexts, because it would swap the rendering thread's DPI-awareness back and forth appropriately.

But this didn't seem like the right trade-off to me in terms of complexity/performance. It would leak some OS-specific details into VulkanPlatformSurfaceSwapChain, and I'm not sure about the perf implications of changing the DPI-awareness so frequently. Also it seems quite dubious that anyone would need this anyway (my case is already unusual, this would be even weirder).

[emezeske]

In case for unfathomable reason anyone wants to know more about this driver bug, I ended up writing up the saga on my devlog: https://anukari.com/blog/devlog/lions-tigers-and-high-dpi-oh-my

Thanks again for the quick review, it is much appreciated as I would like to never think about DPI again.