| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Contains code to make PIXMAN_yv12 fall back to PIXMAN_i420.
Also introduces the idea of an intermediate rendering target. This is
used by the y420 code to make subsampled rendering not look bad.
|
|
The function _pixman_color_space_select_for_composite() selects the best
colorspace for compositing operations. This is the destination's
colorspace if the operator produces identical results as in ARGB or it
is the ARGB colorspace.
If dest, mask and source match the compositing colorspace, fast paths
can be used even if that colorspace is not ARGB.
|
|
Included in this patch is the addition of ROUND_UP_X() macros, that
round up integers to the next multiple of X.
|
|
This is supposed to replace usages of PIXMAN_FORMAT_A().
|
|
YUY2, YVYU, UYVY and VYUY
|
|
Also deprecates the old YUV formats
|
|
Instead of always compositing in ARGB, code can now select the best
color space for compositing. This should be the destination color space
unless the operator is not per-component or the ARGB-to-destination is
nonlinear.
|
|
Code now does not only provide to/from_argb functions, but instead
returns a converter function. This converter function converts from the
given source color space to the given target color space.
Includes an implementation for YUV HD and SD, JPEG is still missing.
|
|
Provides endian-swapped ABGR, which is used in some applications
|
|
This differentiates pixel data from just having a format code to having
a pixel layout - pixman_format_code_t - and color space -
pixman_color_space_t.
No new formats were added, only the option to create unmultiplied ARGB
images exists now.
In the future the general code path will look like this:
Each colorspace provides a "canonical" format. pixman-access.c will
provide accessors to read/write data from/to the image representation to
the canonical format. Additional functions that convert between
different color spaces will be added. These will be called from the
generic store/fetch paths, so the accessors do not need to care about
the color space.
As a first step, compositing will still be done in ARGB, so the general
path will look like this:
src => fetch => convert \
> combine => convert => store => dest
dest => fetch => convert /
Benefits of this approach for adding more formats:
- Minimal changes required to current code.
With a simple check of the color space, all optimizations can continue
working with a minimal performance impact. Even in the general case
optimized store/fetch functions can be used.
- Ease of optimization for common paths
Common cases can be optimized easily. For example, Pixel-aligned
rectangular fills with PIXMAN_OP_SRC and the same color space can
be done with:
src => fetch => store => dest
and not a lot of code is required to do this.
- Extensibility
More color spaces can easily be added later, possibly even making use
of the same accessors for data storage, i.e. linear RGB, more color
matrices for YCbCr or even CMYK.
|
|
This is because planar formats have special requirements about how to
allocate planes, as pixman wants to try to keep the format-specific
requirements of Xv, FFmpeg and GStreamer when allocating the image
memory itself.
|
|
|
|
So far, this function just exposes the desired API. No planar formats
exist that make use of it.
|
|
|
|
Add a new file that carries relevant information for all the different
format codes.
Ideally this would be an array just indexed by format code, but that
requires making pixman_format_code_t a simple enumeration.
Also move pixman_format_supported_source/destination() into the relevant
file.
|
|
Compiling fails otherwise as the debug code uses fprintf
|
|
This is a slight simplification.
|
|
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.
|
|
For gray formats the palettes are indexed by luminance, not RGB, so we
can't use the color storers for gray too.
|
|
|
|
Test gradients under particular conditions (no stops, all the stops
at the same offset) to check that pixman does not misbehave.
|
|
Just like conical gradients, linear and radial gradients can now
have a single stop.
|
|
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).
|
|
|
|
|
|
|
|
These macros are identical to the ones that Tor Lillqvist posted here:
http://lists.freedesktop.org/archives/pixman/2010-April/000160.html
with one exception: the variable is allocated with calloc() and not
malloc().
Cc: tml@iki.fi
|
|
It is apparently broken. See this:
http://mingw-users.1079350.n2.nabble.com/gcc-4-4-multi-threaded-exception-handling-thread-specifier-not-working-td3440749.html
We'll need to support thread local storage on MinGW32 some other way.
Cc: tml@iki.fi
|
|
|
|
This is a small speed-up for the poppler benchmark:
Before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image poppler 4.443 4.474 0.31% 6/6
After:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image poppler 4.224 4.248 0.42% 6/6
|
|
The indexed formats have 0 bits of alpha, but can't be considered
opaque because there may be non-opaque colors in the palette.
|
|
|
|
|
|
Then generalize it and use it for SRC copying between various
identical formats.
|
|
|
|
It doesn't use GTK+ and it was already listed in the non-GTK+ part.
|
|
|
|
|
|
|
|
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.
|
|
The thread local cache is allocated with malloc(), but we rely on it
being initialized to zero, so allocate it with calloc() instead.
|
|
Use the builtin version instead of defining the types ourselves.
|
|
|
