(No comment was entered for this change.)

This happens when there is text with opacity applied, we don't get the cleartype 
edges correct. (Internal bug 1144145 which I'm duping on this.)

Note that this also affects images with alpha channels that additionally have an 
opacity applied to them. The cause is the same as for the cleartype problem, the 
image is composited onto our layer which has our magic transparency color applied to 
it. Although this color is replaced when we composite, the antialiased edges around 
any text or images will have been composited on the wrong color and will look bad.

(No comment was entered for this change.)

[CONFIRMED]

Very similar to http://code.google.com/p/chromium/issues/detail?id=559

SourceForge is a prominent website where this problem occurs:
http://sourceforge.net/projects/wtl (have a look at the green download button)

Attached: Simplified test case.

	opacity-test.html
	459 bytes Download

Note that this problem does not occur if half-transparent black text is rendered on 
white background.

Attached: Modified testcase where the problem does not occur.

	opacity-test-2.html
	455 bytes Download

Please note that the PNG opacity problem occurs when opacity of the bounding object is changed.  That is, 
when opacity of a bounding object (such as a DIV) is less than 100%, any PNG rendered in that bounding 
object will be rendered incorrectly.  This is very bad for any kind of procedural image manipulation, including 
opacity effects.  One cannot fade objects containing PNG images in and out by varying the opacity, for 
example, if the PNG images have any transparency to them, as Chrome will not render those images properly.  
This is a very serious rendering issue for Chrome that is not demonstrated by any other major browser.  The 
primary statement above included the following statement:

"Although this color is replaced when we composite, the antialiased edges around any text or images will have 
been composited on the wrong color and will look bad."

Actually any pixel that is at less than 100% opacity in the PNG image itself appears to get drawn in your magic 
color AND at 100% opacity until the containing object has a CSS opacity of 100%.  Verify this for yourself:

1) Create a PNG image with a transparent region... something like a round button with a gradient drop 
shadow on a transparent BG.  Save this as a PNG24.

2) Place the button into a DIV on a page, or apply it as a CSS background property.

3) Under script control, vary the opacity of the containing DIV.

You will observe that the transparent areas of the PNG will render in your magic color, at 100% opacity, until 
the opacity of the containing object reaches 100%.  At this point, the PNG will render properly.

Frankly speaking, I do not believe this problem is likely to be just one of your compositing engine failing to 
deal with anti-aliased edges properly.  

I'd be happy to set you up with specific test cases if that will help.

Is this bug the same as https://bugs.webkit.org/show_bug.cgi?id=18875 ?

 Issue 4441  has been merged into this issue.

Another simplified test case (from  Issue 4441 )
http://pc44.one.pl/goorol/bugs/chrome_001.htm

I have just entered a similar report to the outstanding issue [2791 in chromium: 
semitransparent .png files is not  shown correctly], it should probably be merged 
with this one. In addition the issue [ Issue 128 : Rounded corners with -webkit-border-
radius with a drop shadow renders as black] is probably also related, and should 
therefore be merged to raise the chances of this getting fix before 1.0.

As an alternative to the description of the bug, here's a zoomed screenshot of the 
problem which anyone who has ever exported a transparent GIF will instantly 
recognize:

	chromium-opacity-bug.png
	969 bytes Download

 Issue 6267  has been merged into this issue.

 Issue 251  has been merged into this issue.

(No comment was entered for this change.)

(No comment was entered for this change.)

Should be fixed in r10637.

Seems so, I just tried the snapshot. thanks!

Yes - this is lovely.  Fantastic work!

 Issue 8075  has been merged into this issue.