| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This avoids a test in the inner loop, which improves performance
especially for tiled sources.
On x86-32, I get these results:
Before:
op=1, src_fmt=20028888, dst_fmt=20028888, speed=306.96 MPix/s (73.18 FPS)
op=1, src_fmt=20028888, dst_fmt=10020565, speed=102.67 MPix/s (24.48 FPS)
op=1, src_fmt=10020565, dst_fmt=10020565, speed=324.85 MPix/s (77.45 FPS)
After:
op=1, src_fmt=20028888, dst_fmt=20028888, speed=332.19 MPix/s (79.20 FPS)
op=1, src_fmt=20028888, dst_fmt=10020565, speed=110.41 MPix/s (26.32 FPS)
op=1, src_fmt=10020565, dst_fmt=10020565, speed=363.28 MPix/s (86.61 FPS)
|
|
This is the common case for a lot of transformed images. If the unit
were negative, the transformation would be a reflection which is
fairly rare.
|
|
|
|
This is a macroized version of SRC/OVER repeat normal/unneeded nearest
neighbour scaling instantiated for some common 8888 and 565 formats.
Based on work by Siarhei Siamashka
|
|
FAST_PATH_SAMPLES_COVER_CLIP:
This is set of the source sample grid, unrepeated but transformed
completely completely covers the clip destination. If this is set
you can use a simple scaled that doesn't have to care about the repeat
mode.
FAST_PATH_16BIT_SAFE:
This signifies two things:
1) The size of the src/mask fits in a 16.16 fixed point, so something like:
max_vx = src_image->bits.width << 16;
Is allowed and is guaranteed to not overflow max_vx
2) When stepping the source space we're guaranteed to never overflow
a 16.16 bit fix point variable, even if we step one extra step
in the destination space. This means that a loop doing:
x = vx >> 16;
vx += unit_x; d = src_row[x];
will never overflow vx causing x to be negative.
And additionally, if you track vx like above and apply NORMAL repeat
after the vx addition with something like:
while (vx >= max_vx) vx -= max_vx;
This will never overflow the vx even on the final increment that
takes vx one past the end of where we will read, which makes the
repeat loop safe.
|
|
|
|
These are useful for macroization
|
|
This lets us simplify some fast paths since we get a consistent
naming that always has 8888 and gets some value for alpha.
|
|
In some cases we end up trying to use the STORE_4 macro with an 8 bit
values, which resulted in other pixels getting overwritten. Fix this
by always masking off the low 4 bits.
This fixes blitters-test on big-endian machines.
|
|
|
|
These macros hide the various types of thread local support. On Linux
and Unix, they expand to just __thread. On Microsoft Visual C++, they
expand to __declspec(thread).
On OS X and other systems that don't have __thread, they expand to a
complicated concoction that uses pthread_once() and
pthread_get/set_specific() to get thread local variables.
|
|
OS X does not support __thread, so we have to check for it before
using it. It does however support pthread_get/setspecific(), so if we
don't have __thread, check if those are available.
|
|
Clears '#warning: "unknown compiler"' messages when building
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
The previous code worked in GNU make, but caused a syntax error in Solaris
make ( https://bugs.freedesktop.org/show_bug.cgi?id=27062 ) - this seems to
work in both, and should hopefully not cause syntax errors in any versions
of make not supporting the macro-substitution-in-macro-name feature, just
cause the macro to expand to nothing.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Pointed out by Andreas Falkenhahn on the cairo mailing list.
|
|
These formats work fine, they just need to have a palette set.
|
|
In SPICE, with Microsoft Visual C++, pixman.h is included after
another file that defines these types, which causes warnings and
errors.
This patch allows such code to just define PIXMAN_DONT_DEFINE_STDINT
to use its own version of those types.
|
|
|
|
|
|
This makes gcc generate slightly better code for optimize_operator.
|
|
This allows us to not test for them later on.
|
|
The four cases for each operator:
none-are-opaque, src-is-opaque, dest-is-opaque, both-are-opaque
are packed into one uint32_t per operator. The relevant strength
reduced operator can then be found by packing the source-is-opaque and
dest-is-opaque into two bits and shifting that number of bytes.
Chris Wilson pointed out a bug in the original version of this commit:
dest_is_opaque and source_is_opaque were used as booleans, but their
actual values were the results of a logical AND with the
FAST_PATH_OPAQUE flag, so the shift value was wildly wrong.
The only reason it actually passed the test suite (on x86) was that
the compiler computed the shift amount in the cl register, and the low
byte of FAST_PATH_OPAQUE happens to be 0, so no shifting actually took
place, and the original operator was returned.
|
|
By extending the operator information table to cover all operators we
can replace the loop with a table look-up. At the same time, base the
operator optimization on the computed flags rather than the ones in
the image struct.
Finally, as an extra optimization, we no longer ignore the case where
there is a mask. Instead we consider the source opaque if both source
and mask are opaque, or if the source is opaque and the mask is
missing.
|
|
http://bugs.launchpad.net/bugs/535183
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=27050
Pixman is not compiling with c++ compiler. During compilation it gives
the following error:
/usr/include/pixman-1/pixman.h:335: error: comma at end of enumerator list
Signed-off-by: Søren Sandmann Pedersen <ssp@redhat.com>
|
|
This patch adds a cache in front of the fast path tables to reduce the
overhead of pixman_composite(). It is fixed size with move-to-front to
make sure the most popular fast paths are at the beginning of the cache.
The cache is thread local to avoid locking.
|
|
|
|
|
|
Since otherwise the workaround won't take effect when you call
pixman_image_composite32() directly.
|
|
|
|
|
|
This fast path function improves performance of 'poppler' cairo-perf trace.
Benchmark from ARM Cortex-A8 @720MHz
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image poppler 38.986 39.158 0.23% 6/6
after:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image poppler 24.981 25.136 0.28% 6/6
|
|
This fast path function improves performance of 'gnome-system-monitor'
cairo-perf trace.
Benchmark from ARM Cortex-A8 @720MHz
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image gnome-system-monitor 68.838 68.899 0.05% 5/6
after:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image gnome-system-monitor 53.336 53.384 0.09% 6/6
|
|
This fast path function improves performance of 'firefox-talos-gfx'
cairo-perf trace.
Benchmark from ARM Cortex-A8 @720MHz
before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image firefox-talos-gfx 139.969 141.176 0.35% 6/6
after:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image firefox-talos-gfx 111.810 112.196 0.23% 6/6
|
|
Restructure the code to use switches instead of ifs. This saves a few
comparisons and make the code slightly easier to follow. Also add some
comments.
|
|
It is more natural to put it where all the other flags are computed.
|
|
Instead of storing it as a boolean in the image struct, just use
another flag for it.
|
|
The new FAST_PATH_IS_OPAQUE flag is computed along with the others in
_pixman_image_validate().
|
|
Instead of calling this function in compute_image_info(), just do the
relevant checks when the extended format is computed.
Move computation of solidness to validate
|
|
Instead of computing the extended format on every composite, just
compute it once and store it in the image.
|
|
This flags indicates that the image is untransformed an
repeating. Such images can be composited quickly by simply repeating
the composite operation.
|
|
Instead of computing all the image flags at composite time, we compute
them once in _pixman_image_validate() and cache them in the image.
|
|
|
|
|
|
|
|
|
|
When a trapezoid sample point is exactly on a polygon edge, the rule
is that it is considered inside the trapezoid if the edge is a top or
left edge, but outside for bottom and right edges.
This program tests that for a1 trapezoids.
|
|
That way they don't confuse the indenting algorithm in editors such as
Emacs.
|
|
Conflicts:
pixman/pixman-sse2.c
|
