359002 - single pixel background image is incorrect color (third line of acid2)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The third line of the acid2 test regressed between Linux nightlies 2006-10-26-04-trunk and 2006-10-27-04-trunk.  It doesn't look particularly easy to simplify a testcase, so it may be easier to figure out by isolating the offending checkin.

Steps to reproduce:
1. load http://www.webstandards.org/files/acid2/test.html#top

Expected results:  No aqua.  Other than the eyes, the test should be just yellow and black.

Actual results:  The 12px high row just above the eyes is aqua instead of yellow.

Possible checkins are:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-10-26+04%3A02&maxdate=2006-10-27+04%3A09&cvsroot=%2Fcvsroot

Comment 1

[Boris Zbarsky [:bzbarsky]]

I don't see any layout changes other than SVG, a focus bug, and some regression tests being added in that range.

I do see a bunch of cairo changes, though none look obviously relevant.

Interestingly, I cannot reproduce the bug over here with Seamonkey builds pulled at MOZ_CO_DATE="Sat Oct 28 00:03:30 CDT 2006" (both cairo and gtk2 GFX)...  I _can_ reproduce with a Firefox build pulled at the same time (!).

No clue what's up with that.

Comment 2

[Robert Sayre]

looks ok on mac.

Comment 3

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

That row has a 1x1 pixel png background, which I handle specially in 357761; it's possible that that part's broken somehow.  I'll take a look tomorrow.

Comment 4

[aja+bugzilla]

(In reply to comment #3)
> That row has a 1x1 pixel png background, which I handle specially in 357761;
> it's possible that that part's broken somehow.  I'll take a look tomorrow.
> 
Looks that way, vlad. Removing the background png url from the css makes it go to red (as expected) instead of aqua.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: simplified testcase

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I put a printf in ThebesDrawTile, and mSinglePixelColor is wrong there -- the r component is 0 instead of the b.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

gfxImageSurface is (maybe) documented as ARGB.  gfxRGBA's constructor is documented as taking ABGR.  (Should they really be different?)  Yet nsThebesImage::Optimize goes from one to the other without conversion.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(And I did confirm by local backout that bug 357761 was the cause.)

Comment 9

[Boris Zbarsky [:bzbarsky]]

For what it's worth, it looks like I had somehow failed to build my thebes seamonkey tree, which is why it wasn't showing the bug...

Comment 10

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

Attachment: fix single-pixel color conversion

dbaron's analysis was correct; I was passing in ARGB to a constructor that expected ABGR.  I tried to make it a little more obvious as to what was going on, to avoid creating this problem in the future.

Comment 11

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

Fix checked in.

Comment 12

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

Attachment: Correctly read in colors for premultiplied source colors, too

Whoops, forgot to read in r/g/b/a for the premultiplied case.

Comment 13

[Boris Zbarsky [:bzbarsky]]

That last checkin isn't likely to be causing the Firefox Mac orange, right?  ;)

Comment 14

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

I sure hope not!