Closed Bug 720035 Opened 8 years ago Closed 8 years ago

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

Categories

(Core :: Graphics, defect)

10 Branch
x86
macOS
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 689962

People

(Reporter: spectre, Unassigned)

References

()

Details

Attachments

(2 files)

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):
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?
Cairo is gfx.
Blocks: 562746
Component: Layout → Graphics
QA Contact: layout → thebes
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.
Summary: mozillazine background is not painted → Completely black images don't paint in Cairo w/o h/w accel
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?
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().
Yup, that fixes it.
You'll want to re-disable it, then look at what's going wrong in imgFrame::Draw().
Err, re-enable it. Remove the environment variable. :)
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?
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.
Oh, wait, I missed that this was not TenFourFox-specific. Yes, please debug further! :)
But if I'm reading that right, that's only when alpha is 0, correct? (Assuming that alpha = 0 to Cairo means completely transparent.)
Wait, I get it now. That's only if there's no alpha *content*.
This sounds like bug 689962
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!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 689962
You need to log in before you can comment on or make changes to this bug.