Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 186281 - Colors messed up with 16bit color depth and XAA for x11-libs/cairo apps
Summary: Colors messed up with 16bit color depth and XAA for x11-libs/cairo apps
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: PPC Linux
: High major (vote)
Assignee: Doug Goldstein (RETIRED)
URL: http://forums.gentoo.org/viewtopic-t-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-23 00:07 UTC by Christian Speckner
Modified: 2008-06-19 14:32 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Modified ebuild for cairo-1.4.6 including patch (cairo.tar.gz,7.27 KB, application/octet-stream)
2007-10-13 11:38 UTC, Christian Speckner
Details
Modified ebuild for cairo 1.4.10 (cairo-1.4.10.ebuild,1.90 KB, text/plain)
2007-10-14 14:31 UTC, Christian Speckner
Details
Patch for cairo-1.4.10; to go with the corresponding ebuild (cairo-1.4.10-goodbye_weird_colors.patch,427 bytes, patch)
2007-10-14 14:33 UTC, Christian Speckner
Details | Diff
Modified ebuild for cairo-1.4.12 (cairo-1.4.12.ebuild,1.97 KB, text/plain)
2007-12-10 00:35 UTC, Christian Speckner
Details
Patch for cairo 1.4.10; to go with the corresponding ebuild (cairo-1.4.12-goodbye_weird_colors.patch,456 bytes, patch)
2007-12-10 00:40 UTC, Christian Speckner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Speckner 2007-07-23 00:07:30 UTC
Colors get messed up when using cairo > 1.4.4 if depth is set to 16 bit. This happens for me on a G4 powermac with a radeon 8500, but also for others with a rage 128 (see http://bugs.freedesktop.org/show_bug.cgi?id=11687). The problem goes away if the depth is set to 24 bit or if the acceleration architecture is set to EXA. I've also added a bug to the cairo tracker from where it in turn was diverted to the radeon tracker as suppesedly not  being a cairo problem, see http://bugs.freedesktop.org/show_bug.cgi?id=11687 . It would be great if anybody with, say, nvidia hardware could try to reproduce this to see if it really is related to readeon/r128 2D code.

I have rolled back git revisions and identified the commit that broke things; I've attached a path to cairo-1.4.6 that fixes the problem for me (a similar path works for 1.4.10). Still, the patch is most likely more a hack than a solution, and since the code in cairo-pattern.c seems to be very much in flux, it may well be that it introduces new problems.


diff --git a/src/cairo-pattern.c b/src/cairo-pattern.c
index b6c8df7..79412ec 100644
--- a/src/cairo-pattern.c
+++ b/src/cairo-pattern.c
@@ -1252,7 +1252,7 @@ _cairo_pattern_acquire_surface_for_solid (cairo_solid_pattern_t        *pattern,
                                          cairo_surface_attributes_t *attribs)
 {
     *out = _cairo_surface_create_similar_solid (dst,
-                                               pattern->content,
+                                               CAIRO_CONTENT_COLOR_ALPHA,
                                                1, 1,
                                                &pattern->color,
                                                &pattern->base);

Reproducible: Always

Steps to Reproduce:
1. Merge recent cairo (stable)
2. change depth to 16 bit, accel method to XXA
3. observe funky colors
Comment 1 Christian Speckner 2007-07-23 00:10:16 UTC
Uups, the first link was of course supposed to be the forum link http://forums.gentoo.org/viewtopic-t-566336.html
Comment 2 Boney McCracker 2007-07-30 09:19:41 UTC
Same here.  Page font colors change variously as I interact with Firefox.  Quite psychedelic, but it renders affected applications unusable.
Comment 3 Christian Schmitt 2007-08-01 09:18:14 UTC
Exactly the same here. iBook G4 with Radeon.
Comment 4 Christian Speckner 2007-10-13 11:38:03 UTC
Created attachment 133322 [details]
Modified ebuild for cairo-1.4.6 including patch

Since I have been using the patch to cairo sice I created it and haven't observed any problems using it, I have created an attachment containing path & ebuild ready to go into an overlay. This is for cairo-1.4.6 (stable), but I can create and post a similar patch for 1-4-10 (testing) if anybody requires it.
Comment 5 Christian Speckner 2007-10-14 14:31:07 UTC
Created attachment 133442 [details]
Modified ebuild for cairo 1.4.10
Comment 6 Christian Speckner 2007-10-14 14:33:46 UTC
Created attachment 133444 [details, diff]
Patch for cairo-1.4.10; to go with the corresponding ebuild

Well, portage development overtook me, since cairo-1.4.10 is now stable, I created and a corresponding fix and attached ebuild and patch. Drop in your local overlay and watch the groovy colors disappear...
Comment 7 Doug Goldstein (RETIRED) gentoo-dev 2007-10-14 22:30:47 UTC
This is going to be a bug in either your driver or a configuration error. Hardcoding this value to alpha is not the correct approach. The point is that this field needs to be adjustable based on the driver that your using or the incoming content since you could have different content. You guys have just proved that the  ati driver always uses alpha.

As you've clearly demonstrated with the X.org guys, it's a bug in the ati driver when using the Render extension. Applying this patch will break graphics for users with other graphics cards or other configurations.
Comment 8 Christian Speckner 2007-10-14 23:40:01 UTC
I'm aware of all this and also am of the opinion that this is most likely a bug in the open source radeon driver (it is definitely NO configuration error). I never suggested including this patch into the official ebuild exactly for the reason you mentioned, but attached the patch and build to the bug as a fix for other people suffering from the same problem (which seems to be ppc specific as no one on another arch has reported something similar, but if you search the forum, this seems to be common on ppc).

Also, I agree with you that the bug should be fixed in the radeon 2D core and not hacked around cairo, but I neither have the skill nor the time to do that. And, finally, I'm also aware what alpha is and that a surface should only be equipped with a alpha channel if it is necessary, but since hardcoding alpha was the way it was treated in cairo before 1.4.6, I don't expect any gross malfunctions.
Comment 9 Boney McCracker 2007-10-14 23:56:21 UTC
(In reply to comment #8)
Right approach or not, I don't see anybody else doing anything about it, so thank you.
Comment 10 Joe Jezak (RETIRED) gentoo-dev 2007-12-03 00:15:25 UTC
ppc should have been CC'd on this...
Comment 11 Doug Goldstein (RETIRED) gentoo-dev 2007-12-05 18:54:06 UTC
Has anyone filed a bug with the radeon driver people at X.org? Has anyone filed a bug with cairo upstream?
Comment 12 Christian Speckner 2007-12-06 10:01:21 UTC
I have filed a bug with cairo as well, from where it was diverted to the radeon/driver people as supposedly not being a cairo issue. The link to the tracker is included in my initial description.
Comment 13 Christian Schmitt 2007-12-06 10:15:28 UTC
I talked to one of the devs at #xorg-devel recently. As it works with EXA he sees no reason to look into the XAA code.
Comment 14 Christian Speckner 2007-12-06 10:29:42 UTC
Last time I tried it, EXA was unstable for me on ppc and crashed frequently. Perhaps I should try again (I believe xorg-server was updated since then) and file another bug on freedesktop if it still crashes.

EXA won't help the r128 people though since this driver implements only XAA.
Comment 15 Christian Schmitt 2007-12-06 11:24:11 UTC
The problem I still see with EXA is that it is slower with drawing the desktop. Yoused it yesterday almost all day but had to switch back to XAA, since the desktop became unusable due to the long drawing time for the windows. They told me on irc that a compositing WM would make it faster. Couldn't test it yet.
Comment 16 Boney McCracker 2007-12-06 13:38:58 UTC
(In reply to comment #13)
> I talked to one of the devs at #xorg-devel recently. As it works with EXA he
> sees no reason to look into the XAA code.
> 

The only way I can make it work on r128 is:
Option "XaaNoOffscreenPixmaps"

But that's not a solution.  I think the tens of thousands of people still using r128 would be grateful to have it fully functional.
Comment 17 Christian Speckner 2007-12-10 00:35:25 UTC
Created attachment 138136 [details]
Modified ebuild for cairo-1.4.12
Comment 18 Christian Speckner 2007-12-10 00:40:28 UTC
Created attachment 138137 [details, diff]
Patch for cairo 1.4.10; to go with the corresponding ebuild

Here is the patch for cairo-1.4.12 (as I noticed that it has gone stable). Btw, EXA seems to be stable for me now, however, I also find that XAA is actually snappier for me (I'm using plain KDE, no compositing).
Comment 19 Doug Goldstein (RETIRED) gentoo-dev 2008-06-19 14:32:04 UTC
alright. I'm closing this bug since it's not a cairo bug but an issue in the driver and the acceleration architecture that the driver is using.

Plain and simple, Cairo can not hack around every single X mis-configuration or driver bug. It'll simply be impossible to maintain.