Instead of mucking around with CFLAGS in configure.ac, preventing
users from setting their own CFLAGS, just define the
PIXMAN_USE_INTERNAL_API and PIXMAN_DISABLE_DEPRECATED in
pixman-private.h
This adds a bilinear fetcher for the case where the image has a scaled
transformation, does not repeat, and the format {ax}8r8g8b8.
Results for the swfdec-youtube benchmark
Before:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image swfdec-youtube 7.841 7.915 0.72% 6/6
After:
[ # ] backend test min(s) median(s) stddev. count
[ 0] image swfdec-youtube 6.677 6.780 0.94% 6/6
These results were measured on a faster machine than the ones in the
previous commit, so the numbers are not comparable.
Signed-off-by: Søren Sandmann Pedersen <sandmann@redhat.com>
Speed up bilinear interpolation by processing more than one component
at a time on 64 bit architectures, and by precomputing the dist{ixiy}
products on 32 bit architectures.
Previously bilinear interpolation for one pixel would take 24
multiplications. With this improvement it takes 12 on 64 bit, and 20
on 32 bit.
This is a small but consistent speedup on the swfdec-youtube
benchmark:
[ # ] backend test min(s) median(s) stddev. count
Before:
[ 0] image swfdec-youtube 18.010 18.020 0.09% 4/5
After:
[ 0] image swfdec-youtube 17.488 17.584 0.22% 5/6
Signed-off-by: Søren Sandmann Pedersen <sandmann@redhat.com>
On Wed, 2009-10-21 at 13:36 +1000, Peter Hutterer wrote:
> On Tue, Oct 20, 2009 at 08:23:55PM -0700, Jeremy Huddleston wrote:
> > I noticed an INSTALL file in xlsclients and libXvMC today, and it
> > was quite annoying to work around since 'autoreconf -fvi' replaces
> > it and git wants to commit it. Should these files even be in git?
> > Can I nuke them for the betterment of humanity and since they get
> > created by autoreconf anyways?
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=24206
As an interim measure, replace AM_INIT_AUTOMAKE([dist-bzip2]) with
AM_INIT_AUTOMAKE([foreign dist-bzip2]). This will prevent the generation
of the INSTALL file. It is also part of the 24206 solution.
Signed-off-by: Jeremy Huddleston <jeremyhu@freedesktop.org>
It was bounding the clip region to INT16_MIN, INT16_MAX, but this was
a relic from the X server. We don't need it since we are already
restricting the clip region to the geometry of the destination.
When masking out the x bits, blitter-test would make the incorrect
assumption that the they were always in the topmost position. This is
not correct for formats of type PIXMAN_TYPE_BGRA.
These generally extracted the 2 bits of alpha, then shifted them 62
bits and replicated across 16 bits. Then they were shifted another 48
bits, making the resulting alpha channel 0.
When masking out the x bits, blitter-test would make the incorrect
assumption that the they were always in the topmost position. This is
not correct for formats of type PIXMAN_TYPE_BGRA.
The first bug is that it is treating the input as if it were a1r1g1b1;
the second one is that the red channel should only be shifted two
bits, not three.
The original Render code used to index pixels with their position in
bits in the image. When the scanline code was introduced pixels were
indexed in bytes, but the FETCH/STORE_4/8 macros still assumed bits.
This commit fixes that by making the FETCH/STORE_4 macros first
convert the index to bit position.
These generally extracted the 2 bits of alpha, then shifted them 62
bits and replicated across 16 bits. Then they were shifted another 48
bits, making the resulting alpha channel 0.
For consistency we will probably want to allow component alpha to be
set on all masks at some point, but this commit only enabled it for
solid images.
This reverts commit 29e22cf38e.
For consistency we will probably want to allow component alpha to be
set on all masks at some point, but not in the stable branch, and this
commit only enabled it for solid images anyway.
This reverts commit 29e22cf38e.
