Prevents Display capture from capturing the first display on creation.
This issue is due to the properties view combo box automatically
selecting the first item in the list by default, but this needs explicit
text anyway to indicate display, so this adds a "[Select a display]"
item that will prevent that from happening and tell the user to select a
display.
This is due to the property view widget not having an item to select, so
it selects the first one, but we want to have specific text for this
anyway, so changing it here is still appropriate. (I don't want to touch
the properties view widget right now for the sake of my sanity)
This race condition is caused when one thread creates a swap chain,
which calls OBS_CreateSwapchainKHR, at the same time another thread
calls OBS_CreateImageView.
OBS_CreateSwapchainKHR allocates swap data, publishes this into the
data->swaps linked list, then initializes it. Meanwhile,
OBS_CreateImageView is iterating the swaps linked list, to see if the
image matches any swap chain images. Due to the order in
OBS_CreateSwapchainKHR, there's no guarantee this data is initialized
so it often ends up running out of bounds on the swap_images array.
The fix is simply to defer the swap data publish to after init.
Add:
Counter-Strike 2, UWP applications, Gaming Services applications,
Microsoft 365(Excel, PowerPoint, Word, Access, OneNote, Outlook,
Publisher and 365 software), Adobe After Effects,
Adobe Character Animator, Adobe Photoshop, Adobe Premiere Pro, Steam,
Epic Games Launcher, Ubisoft Connect, Tencent GUI applications, WeChat
and YY.
Tweak:
Change "Electron" name to "Chromium";
Change "%name% cannot be captured via Game Capture." to
"%name% cannot be captured using Game Capture.".
Remove:
Chrome and Edge (reason is based on Chromium).
Our solution for adding TRANSFER_SRC usage for imageless framebuffers
was triggering validation errors when combined with image view usage
overrides. Add TRANSFER_SRC onto usage overrides for swap chain image
views to fix mismatches.
Switching to a static library that contains version information as
const char strings has multiple benefits:
* The version information provided externally via compiler definitions
will fail compilation early if malformed
* An updated version string (which will happen with every commit) will
not invalidate existing compilation units, because only the static
library is affected by the change
* An update of the version change just requires a recompilation of the
static library and a linker update
* An update of the version will _not_ infect the rest of the codebase
(as it does currently, because everything includes obsconfig.h one
way or another)
* Other modules which used the macro definition directly have been
updated as much as possible to use the proper getter method from
`libobs` instead (some Windows-specific modules use preprocessor
string composition, the value has been added as a compiler definition
directly in those cases)
* Because the impact of a version change due to a commit hash change
is limited to the static library, ccache hit rates should be
improved considerably
