Bug 4260

Created attachment 3057 [details]
Screenshot

Top shown window gtk 2.6 and below.
bottom window, gtk 2.8 with cairo

Can you attach (create an attachment) the output of 'xdpyinfo'? 

Also, in cairo-xlib-surface.c, as an experiment, can you try changing:

-static cairo_bool_t cairo_xlib_render_disabled = FALSE;
+static cairo_bool_t cairo_xlib_render_disabled = TRUE;

and see if that fixes the problem ... this could conceivably be an X
server bug in Sun's implementation of the RENDER extension.

Created attachment 3078 [details]
xdpyinfo

You can forget my other question - it doesn't matter since you don't
have the RENDER extension on your display. (Thought it was in recent
Sun X servers, but perhaps device dependent, or needs to be configured
on...)

The default visual is:

  visual:
    visual id:    0x24
    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

So we have: BGR depth=24, bpp=32, MSBFirst (native for client system)

My guess right now is simply that there are some bugs in the libpixman
code handling BGR pixel formats - they are supposed to be supported so
the comment in cairo-xlib-surface.c:

        /*
         * XXX This can't work.  We must convert the data to one of the
         * supported pixman formats.  Pixman needs another function
         * which takes data in an arbitrary format and converts it
         * to something supported by that library.
         */

Doesn't apply. One thing that could use fixing as an optimization, but
shouldn't be relevant here is that _cairo_xlib_surface_create_similar() on 
a BGR surface should create a BGR or ABGR surface when called on a BGR 
surface. (And same for _cairo_image_surface_create_similar) since
compositing same BGR on BGR is easier than RGB on BGR. (You can typically
just use the same code paths as for RGB.)

Probably the easiest way to debug for those of us lacking a BGR output
device is to hack up the cairo-xlib-surface.c to color-swap on 
GetImage/PutImage to simulate a BGR visual.

alright, anything i can do for now?

Created attachment 3086 [details] [review]
Debugging patch

Here's a patch that reproduces something like the problem - though
it isn't exactly the same I haven't investigated enough to know whether 

 a) it's just a bug in the debugging patch
 b) it actually is the problem you are having not a different one

If you are really desperate for now, you might be able to figure out
how to switch the patch around to convert BGR into RGB rather than
RGB into BGR, but hopefully we'll get a fix pretty soon.

Created attachment 3089 [details] [review]
Debug patch with fix

There was one bug in the debugging patch - used the wrong mask in
one place. Unfortunately, with that fixed, I got problems that were
less similar to what you reported, though I did find two separate
bugs.

Created attachment 3090 [details] [review]
Patch fixing two bugs in libpixman for BGR images

Could you apply the this patch and test with it? It fixes two 
bugs - one with compositing a RGB source onto a BGR destination
and the other with compositing onto BGR destinations in the general
fallback code path.

will do, dunno if i find the time today, but i will try

Created attachment 3092 [details]
compile log

Well, dunno if the patch helps, but it doesn't compiles here.
See attached make output.

Hard to tell from the compile log ... it appears that maybe the patch
didn't apply correctly for you See if there are any spaces after '\' characters
in lines 100-100 of fbpict.h.

Yup, that was it, left over whitespace.
And the patch fixes the but too as far as i can see, no gree anymore :)
:thumbs up:

For what it's worth, the two pixman-bgr-fixes look good to me.

I tried this patch on our solaris install and it works well, building gtk-demo
with the patch produces normal colors ... what this patch does not resolve is
remote display. I applied it to our linux build and when running from linux,
displaying on a solaris screen, the same strange color patches shown in the
original screenshot still appear.

The fixes look good to me.  The && vs & thing is hilarious!

Committed to libpixman. Can you take care of committing to the xserver
tree?

2005-08-28  Owen Taylor  <otaylor@redhat.com>

        Bug #4260, Reviewed by B. Biggs

        * src/fbcompose.c (fbStore_a8b8g8r8, fbStore_x8b8g8r8): Use & not
        && for bitwise AND.

        * src/fbpict.h (fbComposeGetSolid) src/fbpict.c src/fbmmx.c: Take
        'dest' as an argument, if pict and dest don't match for RGB, BGR,
        swap result.

Owen, this fix still needs to be committed to BRANCH_1_0, right?

Hmm, yeah. Now committed to cairo-1-0.

I'm not sure if you can have the IsRGB(dest) != IsRGB(pict) case in the server
code, but I translated the IsRGB() macro as follows:

#define IsRGB(pict) (PICT_FORMAT_TYPE((pict)->format) == PICT_TYPE_ARGB)

The rest applied cleanly.  Fixed in Xserver HEAD.

I don't know if it happens at all currently, but it's certainly a logical
possibility ... RENDER requires supporting a RGB format, so if the server
hardware is natively BGR, then you'll commonly get this mismatch.