306755 - Anti-aliased/semi transparent pixels have random colors when rendered on the canvas

Status: RESOLVED DUPLICATE of bug 293353

(Core :: Graphics: Canvas2D, defect)

Description

[Kamiel Martinet]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050901 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050901 Firefox/1.6a1

Anti aliasing of elements on the canvas is inconsistent. In some cases it does
but in most cases it doesn't.
On my machine the demo ROC showed in his xtech presentation works great and I
don't see anything going wrong with anti-aliasing. When I change the script
slightly the semi transparent pixels produce random colors.
All other elements I've drawn on the canvas don't get correct anti-aliasing and
I've never seen this working properly in firefox (safari on the mac works great)

Reproducible: Always

Steps to Reproduce:
see attachment testcase

Actual Results:  
see attachments

Expected Results:  
render correct anti-aliased and semi-transparent pixels

Comment 1

[Kamiel Martinet]

Attachment: Testcase

Comment 2

[Kamiel Martinet]

Attachment: Screenshot of testcase result

The result I get from the testcase

Comment 3

[Kamiel Martinet]

Attachment: Result of rendering paths on the canvas

Similar rendering problems when using paths

Comment 4

[Kamiel Martinet]

Attachment: Correct anti-aliasing result (on same machine)

This is the ROC demo which works correctly on my machine

Comment 5

[Scott MacGregor]

this test case rendered correctly for me using the 1.5 branch builds. The
reporter was using trunk builds. This could be an invalid bug for the 1.5 branch.

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Which version of Visual Studio are you building with?

Comment 7

[Kamiel Martinet]

It seems I mixed up some of the versions I was looking at (I've several
installed). As far is I can tell the testcase above works on the branch build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050901
Firefox/1.0+

I think this bug can be closed/removed. Sorry for the trouble folks.

Comment 8

[Asa Dotzler [:asa]]

not a branch  bug. unsetting blocker request.

Comment 9

[Agustín Fernández]

CONFIRM - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050904 Firefox/1.6a1

I actually came by this bug when I retested a canvas example I made:

http://www.agustinfernandez.com.ar/proyectos/canvas/.

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I'll ask again:

> Which version of Visual Studio are you building with?

Anything less than VC71 will build cairo incorrectly.

Comment 11

[Kamiel Martinet]

Vladimir,

I don't. I just use the nightly builds.

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ah. The nightly builds are still built with VC6.1; that probably won't change
until Deerk Park ships and people have time to do the infrastructure work.  If
you have access to a linux or OSX machine, those builds should be fine.

Comment 13

[(not currently active) Ted Mielczarek]

Just going to dupe this unless proven otherwise.

Reporter, if you can still reproduce this then let us know.


*** This bug has been marked as a duplicate of 293353 ***

Comment 14

[Agustín Fernández]

I tested it again with both the testcase and the page I mentioned and it still shows random colors (with firefox 1.5 it works correctly). Bug 293353 seems to be different since its testcase now works as expected.

Comment 15

[Agustín Fernández]

I forgot to mention, the build I used is today's nightly:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051206 Firefox/1.6a1

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This is still a dup of 293353; the bug is bad generated assembly code that's only triggered in some cases; enough other things could have changed in cairo on trunk to not trigger the bad codepaths with canvas to make the testcase in 293353 work.

In any case, trunk nightly builds will have a broken build until we do some license checking and upgrade the build machines to VC8.

*** This bug has been marked as a duplicate of 293353 ***