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

RESOLVED DUPLICATE of bug 689962

Status

()

Core
Graphics
RESOLVED DUPLICATE of bug 689962
5 years ago
5 years ago

People

(Reporter: spectre, Unassigned)

Tracking

10 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 590376 [details]
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):
(Reporter)

Comment 1

5 years ago
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
(Reporter)

Comment 3

5 years ago
Created attachment 590613 [details]
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.
(Reporter)

Updated

5 years ago
Summary: mozillazine background is not painted → Completely black images don't paint in Cairo w/o h/w accel
(Reporter)

Comment 4

5 years ago
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().
(Reporter)

Comment 6

5 years ago
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. :)
(Reporter)

Comment 9

5 years ago
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! :)
(Reporter)

Comment 12

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

Comment 13

5 years ago
Wait, I get it now. That's only if there's no alpha *content*.
This sounds like bug 689962
(Reporter)

Comment 15

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 689962
You need to log in before you can comment on or make changes to this bug.