This cairo commit caused the problem: 2d790daa957471670f4ae0d3b22da89e4ee7111f. It was merged into mozilla-central in: 1effb72d30cf The attached patch reverts the 'optimization' that removed the multiplication by alpha. I'll throw a reftest together for this when I get the chance.

This is a regression from 3.5 but I don't think it's that serious. It only breaks single stop gradients with alpha on win32 and it has been broken since March without anyone noticing.

We should add a reftest here.

How about this?

Comment on attachment 421198 [details] [diff] [review] reftest super, thanks

Multi-stop solid gradients are broken too. This patch includes fixes for both cases, but is basically the same as the last one. This one properly passes the reftest that I posted earlier.

reftest.list needs updating to current trunk where I changed when the opacity 01 reftest runs. I think OSX 10.4 support may be going away though.

Backed out die to reftest failures on OSX: REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/mozilla-central-macosx-opt-unittest-everythingelse/build/reftest/tests/layout/reftests/svg/opacity-and-gradient-02.svg |

Here are the failure logs (for OSX debug & optimized runs): http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1263335364.1263338799.19956.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1263338840.1263341556.19260.gz

This happens because OS X doesn't draw the gradient as a solid color. I think it used to because I don't think a ran into this problem when I had the patch against an older version of trunk. roc, doing think any of our gradient changes would cause this behaviour change?

Nevermind, I had thought this passed on the try server. I looked back and it looks like it didn't...

Anyone have any suggestions for how to fix this test?

Does the test pass if the reference uses a single-stop opaque red gradient, and you apply opacity="0.5" to that?

The colors on the left hand side are out by 1 #7F7F00 vs #807F00. It it cairo that is calculating this or does cairo make OS X Core Graphics calls to do this. Tweaking the colours or the opacity may help to sidestep if this is some kind of rounding error when the opacity is applied to the color values. You've gone for red (i.e. FF0000) divided by 2 to get #7F or #80. If you went for some RGB values where the r, g and b values are divisible by 2 you might fare better.

(In reply to comment #14) > The colors on the left hand side are out by 1 #7F7F00 vs #807F00. It it cairo > that is calculating this or does cairo make OS X Core Graphics calls to do > this. Mostly CoreGraphics. > > Tweaking the colours or the opacity may help to sidestep if this is some kind > of rounding error when the opacity is applied to the color values. You've gone > for red (i.e. FF0000) divided by 2 to get #7F or #80. If you went for some RGB > values where the r, g and b values are divisible by 2 you might fare better. I tried this kind of thing without much success. (In reply to comment #13) > Does the test pass if the reference uses a single-stop opaque red gradient, and > you apply opacity="0.5" to that? I'll give this a try.

Comment on attachment 422995 [details] [diff] [review] The patch that landed on trunk a1.9.2.2=beltzner

Reftests have been passed since the check-in happened on trunk and 1.9.2. Given the greenish waterfall on tinderbox I'll mark it verified fixed. Jeff, can you please also set in-testsuite+ for checked-in tests? Thanks.