293726 - colors in svg with cairo-backend: red and blue are swapped...

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Egon Nijns]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8a5) Gecko/20050103
Build Identifier: Gecko/20050510

Blue and red are swapped when using an SVG-enabled mozilla build (with cairo
backend) on Solaris. 

The URL demonstrates the problem: in my build the red and the blue circle have
changed places.



Reproducible: Always

Comment 1

[Leon Sha]

I can not reproduce this problem on sparc platform. Maybe you are in X86
platform? Or this bug has been fixed by other bugs?

Comment 2

[Egon Nijns]

Attachment: circles.svg screenshot showing wrong coloring

This is a screenshot of the described behaviour. This is definately on Solaris
SPARC, but it is as seen on a SunRay1 client (I'm not sure if that is
important).
[the screenshot also shows some other rendering problems, and although I have
seen things like this before I think this is somewhat regressed. For the time
being, I'm not too concerned about these minor problems.]

Some (probably relevant) parts of xdpyinfo:
...
bitmap unit, bit order, padding:    32, MSBFirst, 32
image byte order:    MSBFirst
number of supported pixmap formats:    3
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
...
visual:
    visual id:	  0x20
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff, 0xff00, 0xff0000
    significant bits in color specification:	8 bits
...

I am also seeing the same behaviour as defined in
https://bugzilla.mozilla.org/show_bug.cgi?id=277799 
I'm not sure if these bugs are related...

Comment 3

[Leon Sha]

> This is a screenshot of the described behaviour. This is definately on Solaris
> SPARC, but it is as seen on a SunRay1 client (I'm not sure if that is
> important).

This is the problem. But the real problem is below.

> [the screenshot also shows some other rendering problems, and although I have
> seen things like this before I think this is somewhat regressed. For the time
> being, I'm not too concerned about these minor problems.]
> 
> Some (probably relevant) parts of xdpyinfo:
> ...
> bitmap unit, bit order, padding:    32, MSBFirst, 32
> image byte order:    MSBFirst
> number of supported pixmap formats:    3
> supported pixmap formats:
>     depth 1, bits_per_pixel 1, scanline_pad 32
>     depth 24, bits_per_pixel 32, scanline_pad 32
>     depth 32, bits_per_pixel 32, scanline_pad 32
> ...
> visual:
>     visual id:	  0x20
>     class:    TrueColor
>     depth:    24 planes
>     available colormap entries:    256 per subfield
>     red, green, blue masks:    0xff, 0xff00, 0xff0000

The real problem is here.
I remember this is called pix32b.
I don't remember it is called BGRA or ABGR.
But definitely it is not RGBA.
Normal pix32 color mask is "red, green, blue masks:    0xff0000, 0xff00, 0xff".
I think cairo don't handle such things.
In cairo.h, the defination is here.

typedef enum cairo_format {
    CAIRO_FORMAT_ARGB32,
    CAIRO_FORMAT_RGB24,
    CAIRO_FORMAT_A8,
    CAIRO_FORMAT_A1
} cairo_format_t;

No BGR here.

>     significant bits in color specification:	8 bits
> ...
> 
> I am also seeing the same behaviour as defined in
> https://bugzilla.mozilla.org/show_bug.cgi?id=277799 
> I'm not sure if these bugs are related...

Comment 4

[Egon Nijns]

Attachment: Badly written patch that fixes the color problem on our system

I've put this patch together from the comments of Owen Taylor on a message on
the cairo mailing list (see below). 

There is no cross-endian detection in this patch, since I don't know how to
start with this. Furthermore it is definitely not written very nicely (I also
see some color problems with gradients now...). 

I hope this helps people in similar situations though.


--- cairo mailing list discussion ---

On Tue, 2005-05-10 at 15:04 -0600, Peter Dennis Bartok wrote:
>> Hi all,
>> 
>> Has anyone successfully used Cairo on anything other than a Xfree/Xorg X 
>> server?

>> 
>> Two cases where we are seeing problems are Sun's X server and Hummingbirds' 

>> Exceed Win32 X server. On both or applications usually die with a BadMatch 
>> (in XPutImage or XGetImage). Also, on Servers that have MSB first, cairo 
>> treats it as if they are LSB first, thereby swapping red and blue.
>> 
>> My understanding of the inner workings of cairo and libpixman sadly is quite

>> limited, so I wouldn't know where to start trying to fix this.


No libpixman or Cairo knowledge needed. It's all really shallow inside
cairo-xlib-surface.c.

For the endianess problems, the code simply needs to byte-swap the
image after calling XGetImage / before calling XPutImage if you 
detect cross-endian. (Image byte order not equal to local byte
order.)

(In some cases, there are tricks you can play with calling a 
big endian RGB x888 visual a little endian BGR 888x visual. 
libpixman can draw to a BGR 888x visual but it's going to be 
slow. Certainly simpler to just byte-swap than to worry about
accelerating that.)

It looks to me like the code should work fine on MSB as long
as the client/server endianess matches.

To track down the BadMatch, put a call to 
XSynchronize (display, True) into the program that is producing
the BadMatch, and then get a backtrace. If we know what request
is causing it, it should be pretty simple to track down what is
going on.

Regards,
					Owen

Comment 5

[Egon Nijns]

With a current trunk build this problem is fixed, due to the update of the cairo
library.

If cairo is also updated on the FF1.5 branch this bug can be marked as FIXED.

Comment 6

[Jason Bassford]

Does anybody know what bug caused "the update of the cairo library"?  What bug fixed this?

Comment 7

[Jonathan Watt [:jwatt]]

There wasn't one. It was fixed by vlad updating our version of cairo to latest cairo trunk.