[PATCH] d2d1/tests: Adjust a color to prevent test failures.
Different drivers may produce either #ff7f00 or #ff8000 here, both on Windows and Linux. Signed-off-by: Zebediah Figura <zfigura(a)codeweavers.com> --- Perhaps better would be to avoid depending on pixel-exact color, but it's not clear to me what the preferred way of doing that is. dlls/d2d1/tests/d2d1.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dlls/d2d1/tests/d2d1.c b/dlls/d2d1/tests/d2d1.c index 77899ccd6ea..8548a0a4aa2 100644 --- a/dlls/d2d1/tests/d2d1.c +++ b/dlls/d2d1/tests/d2d1.c @@ -1250,7 +1250,7 @@ static void test_clip(void) translate_matrix(&matrix, 0.1f, 0.0f); ID2D1RenderTarget_SetTransform(rt, &matrix); set_rect(&rect, 110.0f, 250.25f, 150.0f, 300.25f); - set_color(&color, 0.0f, 0.5f, 1.0f, 1.0f); + set_color(&color, 0.0f, 1.0f, 0.0f, 1.0f); ID2D1RenderTarget_PushAxisAlignedClip(rt, &rect, D2D1_ANTIALIAS_MODE_ALIASED); ID2D1RenderTarget_Clear(rt, &color); ID2D1RenderTarget_PopAxisAlignedClip(rt); @@ -1277,7 +1277,7 @@ static void test_clip(void) hr = ID2D1RenderTarget_EndDraw(rt, NULL, NULL); ok(SUCCEEDED(hr), "Failed to end draw, hr %#x.\n", hr); - match = compare_surface(surface, "a958d1fe69ee880200d47b206948e4c1ef382748"); + match = compare_surface(surface, "cb418ec4a7c8407b5e36db06fc6292a06bb8476c"); ok(match, "Surface does not match.\n"); ID2D1RenderTarget_Release(rt); -- 2.25.1
On Mon, 23 Mar 2020 at 03:42, Zebediah Figura <z.figura12(a)gmail.com> wrote:
Different drivers may produce either #ff7f00 or #ff8000 here, both on Windows and Linux.
It should be noted that 0x80 is actually the reasonable way to quantise 0.5f. (I.e., 0.5 * 255 = 127.5, which rounds to 128 both when rounding to nearest even and when rounding half either towards +∞, or away from 0. Other rounding modes exist of course, but would be much more unusual.) Nevertheless, using 0.5f is asking for problems when you need exact results; use either 127.0f / 255.0f for 0x7f, or 128.0f / 255.0f for 0x80.
Perhaps better would be to avoid depending on pixel-exact color, but it's not clear to me what the preferred way of doing that is.
It depends on what you're trying to test. For tests like these, exact colours should be achievable simply by picking reasonable inputs. For things involving more complex calculations like e.g. blending and/or texturing we can probe specific parts of the result with get_readback_colour() + compare_colour(). For cases where we care more about the general shape of the result, there's compare_figure().
participants (3)
-
Henri Verbeet -
Henri Verbeet -
Zebediah Figura