rendervulkan: evict stale screenshot images, for reuse

[oSoMoN]

Fixes a crash that happened when cycling through more than 2 screen recording resolutions in the Steam client: pScreenshotImages would fill up and as a consequence a call to vulkan_acquire_screenshot_texture with a new resolution would return a null pointer.

[oSoMoN]

Note: this PR supersedes #1896.

[misyltoad]

This might conflict with taking a screenshot while in recording

[oSoMoN]

This might conflict with taking a screenshot while in recording

I am indeed seeing a problem. When requesting screenshots in the AVIF format, the resulting files have always the expected dimensions (1280×800). However when requesting screenshots in the PNG format while a screencast is being recorded at a different resolution, the resulting files have either incorrect dimensions, or the dimensions are correct but the texture is repeated horizontally wrapping at the width of the current screencast.

So the PNG screenshot is reusing the texture currently in use by the screencast.

[oSoMoN]

Okay, I can see what's going on with my change. When a PNG screenshot is requested while a screencast is ongoing, vulkan_acquire_screenshot_texture() is incorrectly evicting the first texture in the array that is being used by pipewire, under the assumption that it is not used any longer because its ref count is 0 (because paint_pipewire() calls vulkan_wait() with bReset=true, resetting all command buffers).

It seems that we would be much better off with two separate pools of textures, one for actual screenshots, and one for screencasts?

[oSoMoN]

I am indeed seeing a problem. When requesting screenshots in the AVIF format, the resulting files have always the expected dimensions (1280×800). However when requesting screenshots in the PNG format while a screencast is being recorded at a different resolution, the resulting files have either incorrect dimensions, or the dimensions are correct but the texture is repeated horizontally wrapping at the width of the current screencast.

So the PNG screenshot is reusing the texture currently in use by the screencast.

This is in fact a separate problem: the PNG code path uses currentOutputWidth/currentOutputHeight which are global variables that paint_pipewire() temporarily modifies with the stream's dimensions and then restores. I submitted #2181 to address it separately.

[oSoMoN]

It seems that we would be much better off with two separate pools of textures, one for actual screenshots, and one for screencasts?

I pushed an additional commit that implements this (two separate texture pools, one for screenshots and one for screencasts).