Vulkan: Re-Create main window pipeline and added optional color correction

[SuperRonan]

1. API changes:

• Added ImGui_ImplVulkan_ReCreateMainPipeline(...) to explicitly re-create the main window pipeline (when some of its properties are changed).
• ImGui_ImplVulkan_CreatePipeline(...) does not implicitly use ImGui_ImplVulkan_InitInfo::PipelineRenderingCreateInfo, but a function parameter.
• The main window pipeline is created only if possible during ImGui_ImplVulkan_Init(...) (if a render pass or rendering info are given), else it should be created with ImGui_ImplVulkan_ReCreateMainPipeline(...) before rendering)

2. Concerning color correction:

• The default behavior of imgui_impl_vulkan does not change (no color correction is applied with no overhead in the fragment shader).
• A color correction method is decided at pipeline compile time (through a vulkan specialization constant)
• Color correction parameters can either be set at pipeline compile time (static mode), or through push_constant (dynamic mode, default)
• A gamma correction mode is implemented (and an extra alpha gamma correction since the blending does not necessarily happen in linear color space).
• New color modes can easily be added in the fragment shader.

To illustrate the changes:
Without color correction (the main window pipeline is simply recreated to fit the new swapchain format):

NoColorCorrection.mp4

With color correction:

WithColorCorrection.mp4

[SuperRonan]

See the pull request for the docking branch.

[SuperRonan]

I see there are a number of other PR on a color correction ( #7904, #7826, #578, ...).
Here are some of my thoughts on this subject (probably biased):

• I think the color correction should not be limited to a gamma correction, but other common corrections should be impleted too (HLG, ST2084, DCI-P3, other VkColorSpaceKHR) (although 99% of cases would be covered by a gamma correction)
• Manual color correction in a shader is sometimes necessary (when rendering to a linear format (float or unorm) but with a non linear color space swapchain (like with HDR)).
• I find it surprising that rendering to a RGBA8_UNORM target with sRGB color space "looks correct" without any gamma correction in the shader, but rendering to a RGBA8_SRGB witht the same color space needs an inverse gamma correction in the shader to "look correct". the ImGui color palette appears to be gamma pre-corrected)
• Share the color correction control across all backends:
  • move ImGui_ImplVulkan_ColorCorrectionMethod and ImGui_ImplVulkan_ColorCorrectionParameters to imgui.h as ImGui_ColorCorrectionMethod and ImGui_ColorCorrectionParameters
  • Only use them in renderer backends that implemented color correction.
• I would not put a ImGuiIO::ConfigFlags ImGuiConfigFlags_IsSRGB (Adding sRGB colors to ImGui style. #7826) as I think this behaviour should only be controlled by the renderer impl (as I did in the vulkan impl). ImGuiIO should remain agnostic to color spaces issues (plus ImGuiConfigFlags_IsSRGB does not scale with other color corrections) (plus in vulkan it does not appear to change anything)

[ocornut]

Hello,
I am right that this draft PR should be closed? in favor of #8061 #8110 #8111 ?
It's a bit confusing to deal with PR which all seem to have some overlap in behavior.
Thank you.

[SuperRonan]

Yes this PR can be closed, now that there are #8061, #8111 (and #8110).
Note that #8111 only implements the recreation of the window(s) pipeline(s), not the color correction part. I have a commit built on top of #8111 on my fork that adds color correction, but I wanted #8111 to be merged before submitting it.