ARM: workaround for gcc bug in vshll_n_u8 intrinsic

Some versions of gcc (cs2009q1, 4.4.1) incorrectly reject
shift operand having value >= 8, claiming that it is out of
range. So inline assembly is used as a workaround.

Enable the x888_8_8888 sse2 fast path.

Add CPU detection for VC++ x64

VC++ x64 has no inline assembler and x64 mode supports SSE2.
So, it is unnecessary to call cpuid.

Change names of add_8888_8_8 fast paths to add_n_8_8

The source is solid in those.

Post-release version bump

Pre-release version bump

_pixman_run_fast_path: typo

This is one example of a compiler warning that was lost amit the build
noise.

The error here is that in a list of required conditions we used ';'
instead of '&&' with the result of continuing to use the fast-path
even if we had a wide mask.

Another error is that it was testing src, not mask as it should.

Remove spurious spaces in pixman-x64-mmx-emulation.h

Check if we have posix_memalign() in configure.ac. [23260, 23261]

Fall back to malloc() in blitters-test.c if we don't.

ARM: a fix to pass blitters-test for 'neon_composite_over_n_8_0565'

Inline assembly for handling <8 pixels width did not pass blitters-test.
Fortunately gcc has no problems compiling alternative implementation
which is using RVCT style intrinsics, so it can be used instead.

Post-release version bump

Pre-release version-bump

Merge branch 'blitter-test'

Fix x/y mixup in bits_image_fetch_pixel_convolution()

Bug 23224, reported by Michel Dänzer.

Update CRC value in blitters-test.

At this point, the SIMD, SSE2, MMX and general implementations all
agree.

Various formatting fixes

Add the ability to print intermediate CRC values

Reenable commented-out tests in blitter-test.

The crashes and valgrind issues are all fixed at this point.

One more update to blitters-test - use aligned memory
allocations in order in order to make reproducibility
of alignment sensitive bugs more deterministic
Also testing of masks is reenabled

HACK: updated test to better cover new neon optimizations

Test program for stressing the use of different formats and operators

The code and overall method is mostly based on scaling-test. This one
focuses on trying to stress as many different color formats and types
of composition operations as possible.

This is an initial implementation which may need more tuning. Also
not all color format and operator combinations are actually used.

When cpu specific optimizations are disabled, this test provides
identical deterministic results on x86, PPC and ARM.

Script blitters-test-bisect.rb now works in non-stop mode, until
it finds any problem. This allows to run it for example overnight
in order to test a lot more variants of pixman calls and increase
chances of detecting problems in pixman. Just like with scaling-test,
running blitters-test binary alone with no command line arguments
runs a small predefined number of tests and compares checksum
with a reference value for quick verification.

Delete commented out code in pixman-vmx.c

Misc formatting fixes for pixman-vmx.c

In vmx_combine_atop_reverse_ca() extract alpha after inversing

Really fix vmx_combine_over_reverse_ca()

The inverse destination alpha is just one component, not four.

Fix vmx_combine_out_reverse_ca()

The source alpha is just one component, not four.

Fix vmx_over_reverse_ca()

Destination alpha must be extracted after inversing, otherwise we end
up with 0xFFs in the rgb channels.

Multiply with the alpha of dest, not inverse alpha

Fix vmx_combine_vmx_atop_ca()

It didn't compute the mask correct before.

Fix vmx_combine_over_ca().

In the non-vector code, the mask needs to be multiplied with source
alpha.

In vmx_combine_out_ca() multiply with the alpha of the negated vdest.

Fix vmx_combine_out_ca()

It should multiply with just the destination alpha channel, not all
four channels.

Do the full four-component IN computation in vmx_combine_in_ca().

Fix bug in vmx_combine_xor_ca()

The destination needs to be inverted before the alpha channel is
extracted; otherwise, the RGB channels of da will be 0xff.

Make pix_multiply bit-exact

Change the SSE2 versions of pix_add_multiply() to produce bit-exact results.

Fix a couple of alpha==0 vs src==0 issues in pixman-sse2.c

Rename mmx_composite_add_8888_8_8() to mmx_composite_add_n_8_8().

Fix a couple more alpha==0 vs src==0 bugs in pixman-mmx.c

Make pix_add_mul() in pixman-mmx.c produce exact results.

Previously this routine would compute (x * a + y * b) / 255. Now it
computes (x * a) / 255 + (y * b) / 255, so that the results are
bitwise equivalent to the non-mmx versions.

Rewrite the two-component arithmetic macros.

Previously they were not bit-for-bit equivalent to the one-component
versions. The new code is also simpler and easier to read because it
factors out some common sub-macros.

The x * a + y * b macro now only uses four multiplications - the
previous version used eight.

Fix a bunch of srca == 0 checks that should be src == 0 in pixman-mmx.c

Don't run fast paths if the format requires wide compositing.

This could happen because the wide formats would still be considered
solid if the image was 1x1 and repeating.

Fix bug in combine_mask_alpha_ca()

If the mask was 0xffffffff, the source would end up being shifted
twice by A_SHIFT.

Fix another case of changing the solid source.

This time in fast_path_composite_n_8888_8888().

Fix incorrect optimization in combine_over_ca().

Previously the code assumed that an alpha of 0 meant that no change
would take place. This is incorrect because an alpha of 0 can happen
as the result of the source having alpha=0, but rgb != 0.

Don't change the constant source in fast_composite_over_n_8888_0565.

Fix bugs in combine_over_reverse_ca().

The computation cannot be optimized away when alpha is 0 because that
can happen when the source has alpha zero and rgb non-zero.

Add a dirty bit to the image struct, and validate before using the image.

This cuts down the number of property_changed calls significantly.

Add sse2 version of add_n_8888_8888()

Add a fast path for the add_n_8888_8888() operation.

It shows up on gnome-terminal traces.

Move bounds checks for REPEAT_NONE to get_pixel()

On a P4, this is a large speedup for the swfdec-fill-rate-2xaa trace:

After:

[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]    image        swfdec-fill-rate-2xaa   33.061   33.061   0.00%    1/1

Before:

[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]    image        swfdec-fill-rate-2xaa   40.342   40.342   0.00%    1/1

Pixman 0.14.0 produces this:

[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]    image        swfdec-fill-rate-2xaa   36.896   36.896   0.00%    1/1

Remove leftover 0xffffffff in repeat()

Remove unused function

Misc formatting

Change all the fetch_pixels() functions to only fetch one pixel.

Add fetch_pixel_raw_32 and fetch_pixel_32 virtual functions.

By default both are intialized to bits_image_fetch_pixel_raw(), but if
there is an alpha map, then fetch_pixel_32() is set to
bits_image_fetch_pixel_alpha().

Various renamings and clean-ups

Change bits_image_fetch_alpha_pixels() to fetch just one pixel.

Change bits_image_fetch_pixels_convolution() to fetch just one pixel.

Change bits_image_fetch_bilinear_pixels() to fetch one pixel at a time.

Make the repeat routine work on only one coordinate at a time.

Make bits_image_fetch_nearest() return one pixel.

Previously it would work on a buffer of coordinates.

Change bits_image_fetch_transformed() to work one pixel at a time.

Previously, it would generate a buffer of coordinates, then pass that
off to a pixel fetcher, but this caused a large performance regression
with the swfdec-fill-rate-2xfsaa cairo trace.

This is the first step towards fixing that.

Only define PIXMAN_TIMERS if timers are actually enabled [bug 23169]

Various updates to the CODING_STYLE document

Add a CODING_STYLE document based on the one from cairo.

Remove a couple of unused variables

Rename source_pict_class_t to source_image_class_t

Replace a bunch of 'pict's with 'image'

Explain how we can simplify the radial gradient computation

Soeren rightfully complained that I had removed all the comments from
André's patch, most importantly that explain why the transformation is
valid. So add a few details to show that B varies linearly across the
scanline and how we can therefore reduce the per-pixel cost of evaluating
B.

Fix inversion of radial gradients when r2 > r1

Fixes: Bug 22908 -- Invalid output of radial gradient
http://bugs.freedesktop.org/show_bug.cgi?id=22908

We also include a modified patch by André Tupinambá <andrelrt@gmail.com>,
to pull constant expressions out of the inner radial gradient walker.

Don't warn for empty rectangles, only degenerate ones

Log errors for invalid rectangles passed to region code

Simplify code that logs errors

Make the text when reporting a broken region more useful

Post-release version bump

Pre-release version bump

Don't assert when malformed regions are detected.

Instead print a message to stderr so that it will end up in the X log
file.

Fix another search and replace issue

Fix search-and-replace issue pointed out by Koen Kooi.

Add implementation of MMX __m64 functions for MSVC x64.

Microsoft C++ does not define __m64 and all related MMX functions in
x64.  However, it succeeds in generating object files for SSE2 code
inside pixman.

The real problem happens during linking, when it cannot find MMX functions
(which are not defined as intrinsics for AMD64 platform).

I have implemented those missing functions using general programming.

MMX __m64 is used relatively scarcely within SSE2 implementation, and the
performance impact probably is negligible.

Bug 22390.

Fix read of BITS members from a solid image.

During the fast-path query, the read_func and write_func from the bits
structure are queried for the solid image.

==32723== Conditional jump or move depends on uninitialised value(s)
==32723==    at 0x412AF20: _pixman_run_fast_path (pixman-utils.c:681)
==32723==    by 0x4136319: sse2_composite (pixman-sse2.c:5554)
==32723==    by 0x4100CD2: _pixman_implementation_composite
(pixman-implementation.c:227)
==32723==    by 0x412396E: pixman_image_composite (pixman.c:140)
==32723==    by 0x4123D64: pixman_image_fill_rectangles (pixman.c:322)
==32723==    by 0x40482B7: _cairo_image_surface_fill_rectangles
(cairo-image-surface.c:1180)
==32723==    by 0x4063BE7: _cairo_surface_fill_rectangles
(cairo-surface.c:1883)
==32723==    by 0x4063E38: _cairo_surface_fill_region
(cairo-surface.c:1840)
==32723==    by 0x4067FDC: _clip_and_composite_trapezoids
(cairo-surface-fallback.c:625)
==32723==    by 0x40689C5: _cairo_surface_fallback_paint
(cairo-surface-fallback.c:835)
==32723==    by 0x4065731: _cairo_surface_paint (cairo-surface.c:1923)
==32723==    by 0x4044098: _cairo_gstate_paint (cairo-gstate.c:900)
==32723==  Uninitialised value was created by a heap allocation
==32723==    at 0x402732D: malloc (vg_replace_malloc.c:180)
==32723==    by 0x410099F: _pixman_image_allocate (pixman-image.c:100)
==32723==    by 0x41265B8: pixman_image_create_solid_fill
(pixman-solid-fill.c:75)
==32723==    by 0x4123CE1: pixman_image_fill_rectangles (pixman.c:314)
==32723==    by 0x40482B7: _cairo_image_surface_fill_rectangles
(cairo-image-surface.c:1180)
==32723==    by 0x4063BE7: _cairo_surface_fill_rectangles
(cairo-surface.c:1883)
==32723==    by 0x4063E38: _cairo_surface_fill_region
(cairo-surface.c:1840)
==32723==    by 0x4067FDC: _clip_and_composite_trapezoids
(cairo-surface-fallback.c:625)
==32723==    by 0x40689C5: _cairo_surface_fallback_paint
(cairo-surface-fallback.c:835)
==32723==    by 0x4065731: _cairo_surface_paint (cairo-surface.c:1923)
==32723==    by 0x4044098: _cairo_gstate_paint (cairo-gstate.c:900)
==32723==    by 0x403C10B: cairo_paint (cairo.c:2052)

Only apply the workaround if the clip region extends beyond the drawable.

This works because the X server always attempts to set a clip region
within the bounds of the drawable, and it only fails at it when it is
computing the wrong translation and therefore needs the workaround.

Rework the workaround for bogus X server images.

Bug 22844 demonstrates that it is not sufficient to play tricks with
the clip regions to work around the bogus images from the X
server. The problem there is that if the operation hits the general
path and the destination has a different format than a8r8g8b8, the
destination pixels will be fetched into a temporary array. But because
those pixels would be outside the clip region, they would be fetched
as black. The previous workaround was relying on fast paths fetching
those pixels without checking the clip region.

In the new scheme we work around the problem at the
pixman_image_composite() level. If an image is determined to need a
work around, we translate both the bits pointer, the coordinates, and
the clip region, thus effectively undoing the X server's broken
computation.

Add test case for bug 22844.

Fix typo in sse2_combine_over_pixbuf_0565()

Fix NEON build for older ARM CPUs

The pld instruction used in the NEON assembler code is only available
for ARMv5e and >= ARMv6.

Set -mcpu=cortex-a8 when compiling the source file (similar to what is
already done for the SIMD build).

Some formatting changes to pixman-arm-neon.c

ARM: Fixes for the inline assembly constraints in pixman_fill_neon

Some of the variables in the inline assembly arguments list are
actually modified by the assembly code, they are now marked
appropriately.

ARM: Workaround cs2007q3 compiler bug for NEON registers clobber list

128-bit registers "qX" are incorrectly handled in inline assembly
clobber list for codesourcery cs2007q3 gcc toolchain. Only the
first 64-bit half is saved and restored by gcc. Changing clobber
list to use only 64-bit register aliases can solve this problem.
For example, 128-bit register q0 is mapped to two 64-bit
registers d0 and d1, q1 is mapped to d2 and d3, etc.

ARM: Commented out the rest of buggy NEON optimizations

These functions have problems with invalid memory accesses and often
crash X server

ARM: Use Ian's variant of 'neon_composite_over_n_8_0565' function again

This patch effectively reverts the changes done by commit
8eeeca993252edc39da9c5c57545b81215fafc81 which was causing
severe stability issues, and restores old variant of
'neon_composite_over_n_8_0565' function, which used to work
correctly.

Update Makefile.win32 to make it work again.

Add a lot more sanity checks to region code

- Introduce a GOOD_RECT() macro that checks that a pixman_box_t is not
  empty or degenerate an use it.
- Use GOOD_RECT() instead of magic if statements for funtions that take
  x, y, width, height arguments
- Use GOOD_RECT() in _reset(). The checks in the previous code seemed to
  allow an empty box, but then created a broken region from it.
- Add GOOD(region) check at the end of _translate()

Handle degenerate case in pixman_init_extents()

Create an empty region instead

Replace // comments with /* */ comments in various places

Align the stack in _pixman_implementation_create_sse2()

When compiled without optimization, GCC will place various temporaries
on the stack. Since Firefox sometimes causes the stack to be aligned
to four bytes, this causes movdqa to generate faults.

Check whether the linker understands the hwcap file before using it.

If we're trying to use the GNU linker on Solaris we shouldn't use
our solaris-hwcap.mapfile since it doesn't grok the mapfile format.

Move read and write functions to the bits_image_t struct.

Those fields were duplicated between image_common and bits_image_t
before.