VideoCommon: Move backend_info out of VideoConfig struct. #13403
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I plan to clean up the way VideoConfig is handled and this is step 1.
Both
g_Config
andg_ActiveConfig
had their own copy ofbackend_info
. This was unnecessary since the members were just set once uponVideoBackend
initialization.I've moved
backend_info
from theVideoConfig
struct to be its own global,BackendInfo g_backend_info
. This still isn't ideal, and it should probably exist inside eachVideoBackend
, but it's a baby step in the right direction and I didn't want to make the changes too drastic in one PR.This unfortunately changes a lot of files but I'll explain what I've done:
g_ActiveConfig.backend_info
withg_backend_info
.g_Config.backend_info
withg_backend_info
.VideoConfig
to instead populate aBackendInfo
.BackendInfo
members occur specifically fromVideoBackend
initialization.bSupportsExclusiveFullscreen
. Vulkan on Windows can change this during emulation, but it assigned the value in bothg_Config
andg_ActiveConfig
simultaneously so it was still unnecessary to have two copies. I'll mention that the way this value is used across threads was pretty hacky and it still is, but I'm saving that for another day.I see now that this is redoing work of #11531. That PR certainly has a cleaner end result, but it changes a lot and is in need of a rebase. I'm hoping we can get things moving with smaller steps like I've done here.