The x888 suggests that they have something to do with the x8r8g8b8
formats, but that's not the case; they are assuming a8r8g8b8
formats. (Although in some cases they also work for x8r8g8b8 type
formats).
The palettes for indexed formats must satisfy the condition that if
some index maps to a color C, then the 15 bit version of that color
must map back to the index. This ensures that the destination operator
is always a no-op, which seems like a reasonable assumption to make.
Protect the arguments to the combiner macros with parentheses, and
postfix their temporary variables with underscores to avoid name space
collisions with the surrounding code.
Alexander Shulgin pointed out that underscore-prefixed identifiers are
reserved for the C implementation, so we use postfix underscores
instead.
Under the assumption that pixman gradients are supposed to match
QConicalgradient, described here:
http://doc.trolltech.com/4.4/qconicalgradient.html
this patch fixes two separate bugs in pixman-conical-gradient.c.
The first bug is that the output of atan2() is in the range of [-pi,
pi], which means the parameter into the gradient can be negative. This
is wrong since a QConicalGradient always interpolates around the
center from 0 to 1. The fix for that is to (a) make sure the given
angle is between 0 and 360, and (b) add or subtract 2 * M_PI if the
computed angle ends up outside [0, 2 * pi].
The other bug is that we were interpolating clockwise, whereas
QConicalGradient calls for a counter-clockwise interpolation. This is
easily fixed by subtracting the parameter from 1.
Finally, this patch encapsulates the computation in a new force-inline
function so that it can be reused in both the affine and non-affine
case.
Back in the day, the mask_bits argument was used to distinguish
between masks used for component alpha (where it was 0xffffffff) and
masks for unified alpha (where it was 0xff000000). In this way, the
fetchers could check if just the alpha channel was 0 and in that case
avoid fetching the source.
However, we haven't actually used it like that for a long time; it is
currently always either 0xffffffff or 0 (if the mask is NULL). It also
doesn't seem worthwhile resurrecting it because for premultiplied
buffers, if alpha is 0, then so are the color channels
normally.
This patch eliminates the mask_bits and changes the fetchers to just
assume it is 0xffffffff if mask is non-NULL.
This patch comes from the mozilla central tree. See
http://hg.mozilla.org/mozilla-central/rev/89338a224278 for the
original changeset.
Signed-off-by: Jeff Muizelaar <jmuizelaar@mozilla.com>
Signed-off-by: Egor Starkov <egor.starkov@nokia.com>
Signed-off-by: Rami Ylimaki <ext-rami.ylimaki@nokia.com>
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@nokia.com>
Some of the tests are quite heavy CPU users and may benefit from
using multiple CPU cores, so the programs from 'test' directory
are now built with OpenMP support. OpenMP is easy to use, portable
and also takes care of making a decision about how many threads
to spawn.
This new script can be used to run continuously to compare two test
programs based on fuzzer_test_main() function from 'util.c' and
narrow down to a single problematic test from the batch which results
in different behavior.
This new generalized function can be reused in both blitters-test
and scaling-test. Final checksum calculation changed in order to make
it parallelizable (it is a sum of individual 32-bit values returned
by a callback function, which is now responsible for running test-specific
code). Return values may be crc32, some other hash or even just zero on
success and non-zero on error (in this case, the expected result of the
whole test run should be 0).
This line:
mask = mask | mask >> 8 | mask >> 16 | mask >> 24;
only works when mask has 0s in the lower 24 bits, so add
mask &= 0xff000000;
before.
Reported by Todd Rinaldo on the #cairo IRC channel.
The tls_name_key variable is passed to tls_name_get(), and the first
time this happens it isn't initialized. tls_name_get() then passes it
on to tls_name_alloc() which passes it on to pthread_setspecific()
leading to undefined behavior.
None of this is actually necessary at all because there is only one
such variable per thread local variable, so it doesn't need to passed
as a parameter at all.
All of this was pointed out by Tor Lillqvist on the cairo mailing
list.
