This new API is built on top of std::variant. This allows us to
store many different event types in a space-efficient way and access
the active event type in a type-safe manner that eliminates the
categories of UB that are possible with unions.
Co-authored-by: kimci86 <kimci86@hotmail.fr>
This change was made in 359fe90 due to recommendations from tooling.
On its face this change makes sense since it removes a copy that
isn't always necessary. In practice it caused ergonomic issues due
to now being forced to make a copy of the render states when needed.
The performance gains of eliding this copy are unsubstantiated. We
have not done any profiling to measure its impact. For lack of such
measurements I'd rather err on the side of improved user experience.
If future benchmarks prove this copy is rather expensive then we
can reconsider removing it with that evidence in mind.
While I don't suspect there are any uninitialize variable bugs
present, it's still good to err on the side of safety and provide
an initial value nonetheless.
While you can't easily run these unit tests, it's easy enough to
still compile them so we don't need to go out of way to prohibit
this. CMake has some support for running tests on the target OS
so perhaps in the future we find a compelling way to run the test
suite on a mobile OS.
Character traits are only standardized for character types of which
std::uint8_t is not. All major C++ implementations happen to define
this specialization but because it is not standard C++ they are
allowed to remove it as LLVM has done by deprecating this specialization
in LLVM 18. It is slated for removal in LLVM 19. To avoid compilation
errors and to get ahead of any deprecation warnings when LLVM 18 ships
we need to define our own std::uint8_t character traits.
SFML 4 will have access to C++20's std::u8string which should let us
remove this code.
sf::RenderWindow still inherits a virtual destructor from a base
class so there's no need to explicitly declare a virtual destructor.
I added a test to ensure this property was not broken.
This takes a 4 second configuration time for the entire project with
examples and tests and turns that into 3! Whopping 25% reduction in
configuration time. This effect is likely to be even larger on machines
without exceptionally good internet connections.
Before:
$ hyperfine 'rm -rf build && cmake --preset dev'
Benchmark 1: rm -rf build && cmake --preset dev
Time (mean ± σ): 4.076 s ± 0.130 s [User: 2.148 s, System: 1.376 s]
Range (min … max): 3.963 s … 4.321 s 10 runs
After:
$ hyperfine 'rm -rf build && cmake --preset dev'
Benchmark 1: rm -rf build && cmake --preset dev
Time (mean ± σ): 3.007 s ± 0.313 s [User: 1.061 s, System: 1.160 s]
Range (min … max): 2.783 s … 3.805 s 10 runs
Co-authored-by: binary1248 <binary1248@hotmail.com>
A fun thing about runDisplayTests() is that it means that the tests
won't get run in CI on the DRM code. Technically you can run the
display tests locally when buidling with DRM so these tests will
still fail under those circumstances. Regardless I think this is a
net positive to run the tests in CI.
This class hides a lot of its logic in the private section of the
classes and uses friends to access them so there is little accessible
in the public interface for testing.
Required to satisfy slight differences in how icpx handles
floating point numbers. Only the x value of this vector required
a larger tolerance than normal. Given how many floating point
calculations are required to calculate geometric center, I'm not
surprised to see such a modest deviation.
