720035 - Completely black images don't paint in Cairo w/o h/w accel

Status: RESOLVED DUPLICATE of bug 689962

(Core :: Graphics, defect)

Description

[Cameron Kaiser [:spectre]]

Attachment: screenshot of failure to paint

The Anti-SOPA background on mozillazine does not paint. Observed on both TenFourFox 10b (10.4 PPC) and Firefox 10b (10.5 x86). I'm trying to find a regression window, but the window looks like this (notice the bugzilla search window peeping through because it was not painted over):

Comment 1

[Cameron Kaiser [:spectre]]

This is an old bug.

FAILS: Gecko/20110528 http://hg.mozilla.org/mozilla-central/rev/9260bd59d5ce
WORKS: Gecko/20110526 (there is no nightly build between these dates) http://hg.mozilla.org/mozilla-central/rev/503990b2c5c6

This correlates with the Cairo 1.10 landing.

Both the 10.4 and 10.5 systems are not accelerated. Layout or Gfx?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Cairo is gfx.

Comment 3

[Cameron Kaiser [:spectre]]

Attachment: This JPG should be black

Mozillazine has reverted to their former background, but this image should show the problem. It seems like any totally black image will reproduce this bug.

Comment 4

[Cameron Kaiser [:spectre]]

This URL also shows it (reported by TenFourFox users). The Diablo background (where the artifacts appear) appears black in pre-Cairo 1.10 versions.

Roc, this seems like it should be easy to fix and it disproportionately affects TenFourFox because it is software-only, so I'd like to take a whack at this. What part of Cairo is likely to be the cause?

Comment 5

[Joe Drew (not getting mail)]

My first step would be to check whether image optimization causes this. Quick way to do so is set the environment variable MOZ_DISABLE_IMAGE_OPTIMIZE.

If so, this is a bug caused by imgFrame::Optimize().

Comment 6

[Cameron Kaiser [:spectre]]

Yup, that fixes it.

Comment 7

[Joe Drew (not getting mail)]

You'll want to re-disable it, then look at what's going wrong in imgFrame::Draw().

Comment 8

[Joe Drew (not getting mail)]

Err, re-enable it. Remove the environment variable. :)

Comment 9

[Cameron Kaiser [:spectre]]

It correctly enters DoSingleColorFastPath, sets the operator to OPERATOR_SOURCE (which looks correct) and finishes. Other single colours enter this path but render properly. Is Cairo special-casing black?

Comment 10

[Joe Drew (not getting mail)]

Seems like it does special-case black: http://mxr.mozilla.org/mozilla-central/source/gfx/cairo/cairo/src/cairo-gstate.c#999

"Optimizes" a paint of black (or, incidentally, a paint of a transparent colour) to a clear.

Possibly there's a bug in 10.4 that makes this use of CLEAR not work? You could debug further, and I encourage you to, but you could also just disable that optimization.

Comment 11

[Joe Drew (not getting mail)]

Oh, wait, I missed that this was not TenFourFox-specific. Yes, please debug further! :)

Comment 12

[Cameron Kaiser [:spectre]]

But if I'm reading that right, that's only when alpha is 0, correct? (Assuming that alpha = 0 to Cairo means completely transparent.)

Comment 13

[Cameron Kaiser [:spectre]]

Wait, I get it now. That's only if there's no alpha *content*.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

This sounds like bug 689962

Comment 15

[Cameron Kaiser [:spectre]]

When I make _reduce_op in Cairo simply return the op, the image renders black correctly. So the trick is to convince _reduce_op that there is alpha content present. We know there must be in the image because DoSingleColorFastPath sees that the alpha of the single pixel is 1.0, and sets OPERATOR_SOURCE accordingly. So yes, I think it is bug 689962. Thanks, Jeff and Joe!