Hello all, please bear with me. This email is a bit long-winded!
I'm a contributer to the well know 'Mixbus' Digital Audio Workstation
and to the 'Ardour' DAW on which it is based. Mixbus and Ardour are
open source, cross-platform projects and I work on the Windows versions
which I build
2013/10/5 John Emmas john...@tiscali.co.uk:
From experience, I STRONGLY SUSPECT that the error is caused by these lines
at the top of macro #2:-
#define BILINEAR_INTERPOLATE_ONE_PIXEL_HELPER(pix, phase) \
do {\
__m128i
On 5 Oct 2013, at 19:00, Siarhei Siamashka wrote:
Andrea Canciani has already investigated the problem and submitted the
fixes here:
http://lists.freedesktop.org/archives/pixman/2013-September/002954.html
Many thanks for the super fast response guys. I'm at a different PC now but
The overall goal of the following patches is to make it more obvious
how the blend mode code relates to the specifications. To that end,
the comment for each blend routine is updated with some math that
shows how we go from specification to a formula that can deal with
premultiplied alpha, and the
Fix a bunch of spacing issues.
---
pixman/pixman-combine32.c | 112 +++---
1 file changed, 56 insertions(+), 56 deletions(-)
diff --git a/pixman/pixman-combine32.c b/pixman/pixman-combine32.c
index 3ac7576..be3cfdf 100644
--- a/pixman/pixman-combine32.c
This commit overhauls the comments in pixman-comine32.c regarding
blend modes:
- Add a link to the PDF supplement that clarifies the specification of
ColorBurn and ColorDodge
- Clarify how the formulas for premultiplied colors are derived form
the ones in the PDF specifications
- Write out
Change blend_color_dodge() to follow the math in the comment more
closely.
Note, the new code here is in some sense worse than the old code
because it can now underflow the unsigned variables when the source is
superluminescent and (as - s) is therefore negative. The old code was
careful to clamp
There are no semantic changes, just variables renames. The motivation
for these renames is so that the names are shorter and better match
the one used in the comments.
---
pixman/pixman-combine32.c | 199 +++---
1 file changed, 99 insertions(+), 100
For superluminescent destinations, the old code could underflow in
uint32_t r = (ad - d) * as / s;
when (ad - d) was negative. The new code avoids this problem (and
therefore causes changes in the checksums of thread-test and
blitters-test), but it is likely still buggy due to the use of
