Closed Bug 1427063 Opened 5 years ago Closed 5 years ago

Strange display of transparent background in Google Image Search


(Core :: Graphics, defect, P3)




Tracking Status
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- fixed


(Reporter: 5silentrain, Assigned: bas.schouten)


(Depends on 3 open bugs, Regressed 1 open bug)


(Whiteboard: [needsdiagnosis][platform-rel-Google][gfx-noted])


(5 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171206182557

Steps to reproduce:

For an example, open this link:

Actual results:

Strange display of transparent background in Google Image Search:

Expected results:

In comparison with Chrome:
For what it is worth, not seeing this in Firefox nightly on macOS. Will try on Firefox on Windows (stable and nightly later today hopefully). 

5silentrain can you reproduce this in a fresh profile?
Flags: needinfo?(5silentrain)
I see this issue (class="irc_mi") in Fx58b13 & Fx57.0.3, work fine (class="irc_mut iDVskf3v66ro-HwpH6ZlgJaI", white background) in Fx56.0.2, Win10.

.irc_mi {
    background-color: #fff;
    background-image: linear-gradient(45deg,#efefef 25%,transparent 25%,transparent 75%,#efefef 75%,#efefef),linear-gradient(45deg,#efefef 25%,transparent 25%,transparent 75%,#efefef 75%,#efefef);
Component: Untriaged → Desktop
Ever confirmed: true
Product: Firefox → Tech Evangelism
Version: 57 Branch → Firefox 57
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 (20171229100308)

I've managed to reproduce the issue in a fresh profile on Windows 10 using latest Nightly build and Fx57.0.3.
The issue is not reproducible on MacOS 10.13 nor on Ubuntu 16.04.
OS: Unspecified → Windows
(In reply to Asif Youssuff from comment #1)
> 5silentrain can you reproduce this in a fresh profile?

Flags: needinfo?(5silentrain)
Flags: needinfo?(miket)
Flags: needinfo?(miket)
Whiteboard: [needsdiagnosis][platform-rel-Google]
Attached image bg-firefox.jpg
Attached image bg-chrome.jpg
Attached file tc.html
This tc reproduces the checkboard line thingy in Windows 10 for me.
Priority: -- → P3
Milan, is this a known graphics issue? (see screenshot of tc.html in windows 10)

We get the same content as Chrome, so this likely isn't a site bug.
Flags: needinfo?(milan)
This shows up with D2D content only.
Component: Desktop → Graphics
Flags: needinfo?(milan)
Product: Tech Evangelism → Core
Whiteboard: [needsdiagnosis][platform-rel-Google] → [needsdiagnosis][platform-rel-Google][gfx-noted]
Version: Firefox 57 → Trunk
Bas, is this something that D2D does wrong, or something where we mess up?
Flags: needinfo?(bas)
(In reply to Milan Sreckovic [:milan] from comment #11)
> Bas, is this something that D2D does wrong, or something where we mess up?

Hrm, I really want to say D2D, this can't really be a bug in the D2D backend since we don't really manipulate any of the graphics primitives on that level before passing it to D2D. (Fwiw I did check this on edge just for good measure and it doesn't reproduce the issue) Having said that, we do do some special things for gradients and repeating them iirc. I will look into this.
Assignee: nobody → bas
Flags: needinfo?(bas)
Alright, it doesn't look like we still have 'special' code inside D2D to deal with Gradients. I suspect this has something to do with the way D2D draws gradients which doesn't snap things in the same way Skia does. The bug has to be fixed somewhere inside nsCSSGradientRenderer::Paint I think, where we do some strange things for repeating gradients. Ryan, looking at the blame for that file you're the only person still at Mozilla who has recently dealt with this code, do you have any idea what might be the problem here?
Flags: needinfo?(rhunt)
To be a little more precise, I suspect we're manually drawing the gradient repeated along the diagonal axis, in this area, the edges of the two repeats subtly 'overlap' causing antialiasing artifacts (for example) 0.5 and 0.5 covered  covered pixels both covered with 0.5 transparency now become 0.75 transparent. (0.5 * (1 - 0.5) + 0.5).
Okay so we're running into two issues here, the first is our handling of premultiplied alpha color stops [1]

We insert additional stops to fake premultiplied alpha transitions between stops as our backends transition color stops with straight alpha. This code is causing us to do a weird transition between #efefef to transparent. If you replace transparent with white, the dark gray disapears.

I don't really understand how this code works. It looks like both Skia and Direct2D support native premultiplied color transitions with flags. [2][3] From my limited testing using this flag with D2D and removing this code fixes the dark gray.

The other issue is that there appears to be some white gaps between tiles even with this change. We pixel snap each repetition of a tile individually. Commenting out the code that does that made some edges a little more blurry, but removed the gaps and made it look okay and very close to chrome.

I think nical was potentially going to make some changes to our pixel snapping here, I'd be curious if that helps us here.

Flags: needinfo?(rhunt)
Depends on: 1087857, 1087119
Comment on attachment 8970175 [details]
Bug 1427063: Have D2D interpret colors in premultiplied space. As it says is its default.

Attachment #8970175 - Flags: review?(rhunt) → review+
Pushed by
Have D2D interpret colors in premultiplied space. As it says is its default. r=rhunt
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Depends on: 1474133
Depends on: 1509396
Regressions: 1622549
You need to log in before you can comment on or make changes to this bug.