[cairo] [PATCH] Updates for the scaling test and more fixes

[Soeren Sandmann]

Siarhei Siamashka <siarhei.siamashka at nokia.com> writes:

> Now test provides better coverage for various image scaling
> cases. Unused byte for x8r8g8b8 format is ignored. Running
> the test program without any command line options provides
> a PASS/FAIL verdict based on the precalculated crc32 value
> for using pixman with all the fastpath functions disabled,
> which should simplify testing for correcteness.

Pushed.

> From d7b7a4e4e78e48b76d9596276ee9a2c1d68c4451 Mon Sep 17 00:00:00 2001
> From: Siarhei Siamashka <siarhei.siamashka at nokia.com>
> Date: Mon, 20 Apr 2009 16:22:42 +0300
> Subject: [PATCH] Fixed rendering bug for source alpha == 0 in OVER fastpath functions
> 
> Handling of the case when source alpha is zero was keeping destination
> pixel unmodified. But this is different from how generic path behaves.
> For example fbOver(0x00200483, 0x9CAC7E9F) == 0x9CCC82FF and the
> destination pixel changes from 0x9CAC7E9F to 0x9CCC82FF in spite
> of having zero alpha.

It is true that pixels with alpha=0 and color channels != 0 can't be
skipped, but the 

        if (a)

optimization is actually fairly important because memory access is so
expensive. So a better fix is to check that the whole source is 0
rather than just the alpha.

> From afbfb6405d63b196960a2acc5f3a12f2d3f1686a Mon Sep 17 00:00:00 2001
> From: Siarhei Siamashka <siarhei.siamashka at nokia.com>
> Date: Mon, 20 Apr 2009 16:32:14 +0300
> Subject: [PATCH] Removed unnecessary processing of undefined byte for x8r8b8g8 format
> 
> Top 8 bits of x8r8g8b8 format are undefined as explained in:
> http://lists.cairographics.org/archives/cairo/2009-April/016902.html

This one does not apply anymore after Jeff pushed the ARM fast paths,
but looks otherwise good. Can you resend it, or publish a link to a
git repository?

(It could be argued that we should treat the x8 channel only as
undefined on read, and leave it alone when writing, but it's probably
not worth the performance impact of an extra memory read per pixel).

> From 90f8369894b28cc3cca757a329352fe19943de16 Mon Sep 17 00:00:00 2001
> From: Siarhei Siamashka <siarhei.siamashka at nokia.com>
> Date: Mon, 20 Apr 2009 16:36:08 +0300
> Subject: [PATCH] Removal of unused fbCompositeSrc_8888x0888 function

Did you try enabling it in the fast path table? Apart from the same
alpha issue as above, it seems fine to me.

Its parameters as far as I can tell would be

        PIXMAN_OP_OVER, PIXMAN_a8r8g8b8, PIXMAN_null, PIXMAN_r8g8b8
        PIXMAN_OP_OVER, PIXMAN_a8b8g8r8, PIXMAN_null, PIXMAN_b8g8r8

These functions, on the other hand:
        
        fbCompositeSolidMask_nx1xn()
        fbCompositeSrcAdd_1000x1000()
        fbCompositeSrcSrc_nxn()

I think we can just delete. If we add core drawing to pixman some day,
they can be resurrected.


Thanks,
Soren