Bug 4260 - Antialised font is rendered over green background
Summary: Antialised font is rendered over green background
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: 0.9.3
Hardware: SPARC Solaris
: high major
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
Depends on:
Reported: 2005-08-26 14:09 UTC by Barbie LeVile
Modified: 2005-09-18 04:05 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Screenshot (66.17 KB, image/png)
2005-08-26 14:11 UTC, Barbie LeVile
xdpyinfo (5.49 KB, text/plain)
2005-08-28 09:26 UTC, Barbie LeVile
Debugging patch (3.19 KB, patch)
2005-08-28 10:51 UTC, Owen Taylor
Details | Splinter Review
Debug patch with fix (3.19 KB, patch)
2005-08-28 12:38 UTC, Owen Taylor
Details | Splinter Review
Patch fixing two bugs in libpixman for BGR images (6.97 KB, patch)
2005-08-28 12:39 UTC, Owen Taylor
Details | Splinter Review
compile log (15.64 KB, text/plain)
2005-08-28 13:43 UTC, Barbie LeVile

Description Barbie LeVile 2005-08-26 14:09:20 UTC
Antiliased fonts are rendered over a green background.
see screenshot: http://www.gods-inc.de/barbie/solaris/funkytext.png

Other information:
Cairo 1.0.0
gtk+ 2.8.2
glib 2.8.1
pango 1.9.1
atk 1.10.1
glitz 0.4.4

SunOS hel 5.10 Generic_118822-08 sun4u sparc SUNW,Sun-Blade-1000
XVR-1000 Graphics board
Software compiled with Sun Studio 10
Comment 1 Barbie LeVile 2005-08-26 14:11:00 UTC
Created attachment 3057 [details]

Top shown window gtk 2.6 and below.
bottom window, gtk 2.8 with cairo
Comment 2 Owen Taylor 2005-08-27 19:02:25 UTC
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.
Comment 3 Barbie LeVile 2005-08-28 09:26:15 UTC
Created attachment 3078 [details]
Comment 4 Owen Taylor 2005-08-28 10:12:10 UTC
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

The default visual is:

    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.
Comment 5 Barbie LeVile 2005-08-28 10:41:56 UTC
alright, anything i can do for now?
Comment 6 Owen Taylor 2005-08-28 10:51:46 UTC
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.
Comment 7 Owen Taylor 2005-08-28 12:38:07 UTC
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
Comment 8 Owen Taylor 2005-08-28 12:39:59 UTC
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.
Comment 9 Barbie LeVile 2005-08-28 13:00:26 UTC
will do, dunno if i find the time today, but i will try
Comment 10 Barbie LeVile 2005-08-28 13:43:31 UTC
Created attachment 3092 [details]
compile log

Well, dunno if the patch helps, but it doesn't compiles here.
See attached make output.
Comment 11 Owen Taylor 2005-08-28 14:40:31 UTC
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.
Comment 12 Barbie LeVile 2005-08-28 14:57:35 UTC
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:
Comment 13 Carl Worth 2005-08-30 09:08:02 UTC
For what it's worth, the two pixman-bgr-fixes look good to me.
Comment 14 Tobias Oetiker 2005-09-08 02:23:14 UTC
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.
Comment 15 Billy Biggs 2005-09-08 20:51:09 UTC
The fixes look good to me.  The && vs & thing is hilarious!
Comment 16 Owen Taylor 2005-09-12 05:56:56 UTC
Committed to libpixman. Can you take care of committing to the xserver

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.
Comment 17 Carl Worth 2005-09-12 10:56:15 UTC
Owen, this fix still needs to be committed to BRANCH_1_0, right?
Comment 18 Owen Taylor 2005-09-16 06:44:21 UTC
Hmm, yeah. Now committed to cairo-1-0.
Comment 19 Billy Biggs 2005-09-18 20:42:24 UTC
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.
Comment 20 Owen Taylor 2005-09-18 21:05:32 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.