When dealing with calculations that are fundamentally two dimensional
it's helpful to use a 2D data type as much as possible rather than
decomposing the calculations into x and y components. The more we use
vector operations the better chance we have of easiliy reasoning about
what the code is doing.
The two headers only differed in their inclusions and two type
aliases. It's easier to use the preprocessor than the maintain two
nearly identical files.
This layer of indirection was unnecessary. All of its functions
were only used once somewhere inside of Image.cpp. The code is shorter
and simpler and easier to reason about if we put the implementations
of these functions directly in Image.cpp.
Because CI didn't cover this code we didn't know there were
warnings in these codepaths to address.
Not sure why GCC's -Wduplicated-branches is being emitted or how
exactly to fix it. It's easier to simply ignore it in this one
particular file.
The flakiness is theoretically limited to Linux where we have to
use xvfb-run in CI. Because the tests are ran on Linux via ctest
we can more easily use CTest's built-in support for rerunning
failed tests. We have yet to actually observe this flakiness after
the other changes added in #2474 so it's possible the flakiness
has been entirely addressed.
While I was at it I de-duplicated some code for printing OpenGL
information.
Version 12 changes to URCT instead of MSVCRT which causes linker
issues with all the prebuilt MinGW binaries. This is still a liability
that will have to eventually be fixed.
There were 6 copies of InputImpl.hpp for Windows, macOS, Linux,
Linux DRM, iOS, and Android. All but Windows and Linux DRM were
identical so there's already an easy opportunity for consolidation.
The Windows header included some additional private static functions
and data. An equivalent way of expressing this is via more data and
functions instead the anonymous namespace of Win32/InputImpl.cpp so
that's what I did. To fix some issues with functions being used
before they're defined I moved number of functions into the anonymous
namespace of that file which resulted in adding `sf::` in lots of places.
InputImplUDev.hpp used by the DRM backend was trickier because includes
WindowImplDRM as a friend. This creates a weird dependency graph where a
distant class can call private functions that mutate private state. I
kept the definitions of those functions inside DRM/InputImpl.cpp while
moving their declaration to WindowImplDRM.cpp which is the only file
where they're used. This is a bit odd but it avoids using the
preprocessor and ensures that only the file that needs these functions
can call them.
In the end I was able to delete all 6 separate copies of InputImpl.hpp
and consolidate them into src/SFML/Window/InputImpl.hpp saving nearly
1,000 lines of code.
Because `sf::priv::InputImpl` is merely a set of static functions I
converted this class to a simple namespace. The use of a namespace is
what ultimately allowed me to untangle the DRM functions that were not
present in other implementations
