A new command line argument allows the user to specify which one of
the regressions should be run.
---
test/pixel-test.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/test/pixel-test.c b/test/pixel-test.c
index 1ff4d8c..9d2831d 100644
--- a/test/pixel-test.c
++
Support is added to pixel-test for verifying operations involving
masks. If a regression includes a mask, it is verified with the
pixel_checker API in in both unified and component alpha modes.
---
test/pixel-test.c | 86 ---
1 file changed, 75 i
The following patch series,
(1) Extends the test suite with a new 'tolerance-test' which is
similar in spirit to 'composite', except that it supports more
operators, uses random pixels as input, and isn't limited to 1x1
images.
(2) Fixes a bunch of bugs in the blend mode operators, first reported
From: Søren Sandmann Pedersen
---
test/check-formats.c | 16
1 file changed, 16 insertions(+)
diff --git a/test/check-formats.c b/test/check-formats.c
index 7edc198..8eb263b 100644
--- a/test/check-formats.c
+++ b/test/check-formats.c
@@ -146,6 +146,22 @@ static const pixman_op
From: Søren Sandmann Pedersen
This new test program is similar to test/composite in that it relies
on the pixel_checker_t API to do tolerance based verification. But
unlike the composite test, which verifies combinations of a fixed set
of pixels, this one generates random images and verifies that
From: Søren Sandmann Pedersen
In the component alpha part of the PDF_SEPARABLE_BLEND_MODE macro, the
expression ~RED_8 (m) is used. Because RED_8(m) gets promoted to int
before ~ is applied, the whole expression typically becomes some
negative value rather than (255 - RED_8(m)) as desired.
Fix t
From: Søren Sandmann Pedersen
The implementations are copied from the floating point pipeline, but
use double precision instead of single precision.
---
test/utils.c | 182 +--
1 file changed, 178 insertions(+), 4 deletions(-)
diff --git a
From: Søren Sandmann Pedersen
This commit fixes four separate bugs:
1. In the computation
(1 - sa) * d + (1 - da) * s + sa * da * B(s, d)
we were using regular addition for all four channels, but for
superluminescent pixels, the addition could overflow causing
nonsensical result
From: Søren Sandmann Pedersen
Consider a HARD_LIGHT operation with the following pixels:
- source: 15 (6 bits)
- source alpha: 255 (8 bits)
- mask alpha: 223 (8 bits)
- dest 255 (8 bits)
- dest alpha: 0 (8 bits)
Since 2 times the sou
An upcoming commit will delete many of the operators from
pixman-combine32.c and rely on the ones in pixman-combine-float.c. The
comments about how the operators were derived are still useful though,
so copy them into pixman-combine-float.c before the deletion.
---
pixman/pixman-combine-float.c |
Consider a DISJOINT_ATOP operation with the following pixels:
- source: 0xff (8 bits)
- source alpha: 0x01 (8 bits)
- mask alpha: 0x7b (8 bits)
- dest: 0x00 (8 bits)
- dest alpha: 0xff (8 bits)
When (src IN mask) is computed in 8 bits, the resulting alpha channel
is 0 due to rou
The Soft Light operator has several branches. One them is decided
based on whether 2 * s is less than or equal to 2 * sa. In floating
point implementations, when those two values are very close to each
other, it may not be completely predictable which branch we hit.
This is a problem because in on
Søren Sandmann wrote:
Consider a DISJOINT_ATOP operation with the following pixels:
- source: 0xff (8 bits)
- source alpha: 0x01 (8 bits)
- mask alpha: 0x7b (8 bits)
- dest: 0x00 (8 bits)
- dest alpha: 0xff (8 bits)
When (src IN mask) is computed in 8 bits, the resulting alp
My coworker Anthony and I have been working on the WinCairo port of WebKit
which includes pixman. We were having it crash when delay loading the dlls
on Windows XP because of improper usage of __declspec(thread). We are
using the MinGW code with Visual Studio. I'm not familiar with pixman
coding
14 matches
Mail list logo
