- Simplified public API, simplified backend interface.
- Camera device hotplug events.
- Thread code is split up so it backends that provide own threads can use it.
- Added "dummy" backend.
Note that CoreMedia (Apple) and Android backends need to be updated, as does
the testcamera app (testcameraminimal works).
Eventually we can re-add a fast path for that data down to the individual renderers. Setting color scale would still require converting to float, and most hardware accelerated renderers prefer to consume colors as float, so this requires some thought and performance testing.
Fixes https://github.com/libsdl-org/SDL/issues/9009
We either need to explicitly test using the sRGB colorspace or update the tests for HDR10 color conversion. We'll just disable them for now, as these formats aren't commonly used in games.
The renderer will always use the sRGB colorspace for drawing, and will default to the sRGB output colorspace. If you want blending in linear space and HDR support, you can select the scRGB output colorspace, which is supported by the direct3d11 and direct3d12
These originally checked for expected ± EPSILON as logged, but since
commit 880c6939 they check for expected ± max_err, where max_err may
need to be greater than EPSILON for very large expected results like
the ones in exp_regularCases().
Also, EPSILON is so small that the default precision of the %f format
(6 decimal places) would never actually have shown its effect, so log
it in scientific notation instead.
Fixes: 880c6939 "testautomation_math: do relative comparison + more precise correct trigonometric values"
Signed-off-by: Simon McVittie <smcv@collabora.com>
While looking at the other tests in this file, I noticed that instead
of checking for a result in the range of expected ± FLT_EPSILON as I
would have expected, these tests would accept any result strictly less
than expected + FLT_EPSILON, for example a wrong result that is very
large and negative. This is presumably not what was intended, so add
the SDL_fabs() that I assume was meant to be here.
Fixes: 474c8d00 "testautomation: don't do float equality tests"
Signed-off-by: Simon McVittie <smcv@collabora.com>
If the magnitude of the expected result is small, then we can safely
assume that the actual calculated result matches it to 10 decimal
places.
However, if the magnitude is very large, as it is for some of our exp()
tests, then 10 decimal places represents an unrealistically high level
of precision, for example 24 decimal digits for the test that is
expected to return approximately 6.6e14. IEEE 754 floating point only
has a precision of about 16 decimal digits, causing test failure on
x86 compilers that use an i387 80-bit extended-precision register for
the result and therefore get a slightly different answer.
To avoid this, scale the required precision with the magnitude of the
expected result, so that we accept a maximum error of either 10 decimal
places or 1 part in 1e10, whichever is greater.
[smcv: Added longer commit message explaining why we need this]
(cherry picked from commit 880c69392a)
In the Steam Runtime 1 'scout' environment, when compiling for i386
using the default gcc-4.6, Exp(34.125) matches the desired value to the
precision shown in the log (6 decimal places) but is not an exact match
for the desired value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
