Although BSCMAKE is still installed with Visual Studio,
it is no longer used by the IDE.
Since Visual Studio 2008, browse and symbol information is stored
automatically in a SQL Server .sdf file in the solution folder.
Allow multiple bootstrap entries for a single video driver with the same name, which internally allows preferential and fallback init conditions while hiding the implementation details from applications (e.g. applications will just see "wayland", regardless of whether it's using the preferred or fallback driver list entry).
If a driver is requested, all instances of it in the list will be tried before reporting failure, and client applications programmatically enumerating the video drivers will be presented with a deduplicated list of entries.
Wayland has a myriad of unresolved problems regarding surface suspension
blocking forever in QueuePresent/SwapBuffers when occludedand the FIFO
(vsync) implementation being fundamentally broken leading to reduced
GPU-bound performance and 'barcoding' frametimes due to swapchain
starvation.
There are two protocols used to solve these two problems together --
fifo-v1 and commit-timing-v1, which implement the commit queue on the
compositor side, and a timestamp that frames are intended to be
displayed for/discarded respectfully.
To avoid severe performance regressions for developers targeting SDL3,
only pick Wayland as the default backend when these two protocols are
supported -- otherwise fallback to X11/XWayland.
We do this by having two VideoBootStraps, one which is tests the
preferred case, "wayland_preferred" (ie. if fifo-v1 + commit-timing-v1
are available init time), and the fallback, which is just "wayland",
the same name as before, which does no such tests.
Thus, forcing with SDL_VIDEO_DRIVER=wayland will go onto the fallback
option, and pick Wayland always, as usual, so there is no behaviour
change.
In the case that X11/XWayland is not available (ie. no DISPLAY), we will
still fallback to using Wayland without these protocols available.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
