1364774 - Visual glitch (horizontal line) in checkboxes in preferences panel

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Flore Allemandou [:flore]]

Attachment: 2nd checkbox shows an horizontal line

I noticed visual glitches on checkboxes in the preferences panel (General, Firefox accounts, privacy and security).

On some checkboxes (not all), an horizontal line appears on the top quarter of the checkbox. It does not matter if this checkbox is originally checked or not. It seems to disappear on empty checkboxes when the mouse hovers it, but it comes back when the page is reloaded. Andit does not disappear on a checked checkbox.

No idea if it is specific to Mac OSX or not. I think it is related to proton since I activated proton in about:config

Version 	55.0a1
Identifiant de compilation 	20170514030207

Comment 1

[Guilherme Lima]

I'm seeing the same thing on Windows 7 on latest Nightly.

Comment 2

[Flore Allemandou [:flore]]

I checked on windows too and the bug is still present.
However it is not specific to photon (which I did not activate on my windows machine)

Comment 3

[Flore Allemandou [:flore]]

I'm trying to get a fully functional mozregression on OSX.

At the moment, I can only get a regression window by bisection, not by taskcluster:

INFO: Last good revision: 838652a84b76c273e084d0705f3f4f3be89520a8 (2017-05-11)
INFO: First bad revision: 8a7d0b15595f9916123848ca906f29c62d4914c9 (2017-05-12)
INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=838652a84b76c273e084d0705f3f4f3be89520a8&tochange=8a7d0b15595f9916123848ca906f29c62d4914c9

Comment 4

[Flore Allemandou [:flore]]

I finally got mozregression to work completely... Here is a narrower regression window :

INFO: Narrowed inbound regression window from [c1719e0d, ad45e59c] (3 revisions) to [c1719e0d, 2a8e0c4b] (2 revisions) (~1 steps left)
INFO: No more inbound revisions, bisection finished.
INFO: Last good revision: c1719e0d676b56ccd940c6f8a9b1bb819d441b20
INFO: First bad revision: 2a8e0c4be57d244bf59543750d047b2ab7c8bbdc
INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c1719e0d676b56ccd940c6f8a9b1bb819d441b20&tochange=2a8e0c4be57d244bf59543750d047b2ab7c8bbdc

Comment 5

[Alice0775 White]

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e6daa01f4c3ca434da646e1329cb9795b71539d4&tochange=e06077091df1f2577a052b43e86135cc12e87a4c

Regressed by : Bug 1340627

@[e-mail],
Could you look this?

Comment 6

[Lee Salzman [:lsalzman]]

(In reply to Flore Allemandou [:flore] from comment #0)
> Created attachment 8867560 [details]
> 2nd checkbox shows an horizontal line
> 
> I noticed visual glitches on checkboxes in the preferences panel (General,
> Firefox accounts, privacy and security).
> 
> On some checkboxes (not all), an horizontal line appears on the top quarter
> of the checkbox. It does not matter if this checkbox is originally checked
> or not. It seems to disappear on empty checkboxes when the mouse hovers it,
> but it comes back when the page is reloaded. Andit does not disappear on a
> checked checkbox.
> 
> No idea if it is specific to Mac OSX or not. I think it is related to proton
> since I activated proton in about:config
> 
> Version 	55.0a1
> Identifiant de compilation 	20170514030207

I tried reproducing this on Mac with latest nightly, and I was not able to do so. Everything looked fine.

Can you please paste the "Graphics" section of about:support? That might shed a bit more light on what is going on.

Comment 7

[Alice0775 White]

Attachment: about:support on Windows10

Comment 8

[Flore Allemandou [:flore]]

Attachment: about:support on windows 7 affected by the bug

Right now I'm at work on a windows machine (also affected). I will send the same info from my iMac tonight european time (morning pacific time).

I have an iMac mid 2011 with an AMD Radeon HD 6770M graphic card (that's all I can remember by now).
I will ask my boyfriend to check if his 2010 mac pro is affected or not and send the same information.

Comment 9

[Alice0775 White]

FYI,
Setting gfx.content.azure.backends = direct2d1.1,cairo should fix.

Comment 10

[Flore Allemandou [:flore]]

On my windows 7, I have to change only gfx.canvas.azure.backends  = direct2d1.1,cairo to fix it (not content and not both)

Comment 11

[Flore Allemandou [:flore]]

Attachment: about:support on MacOSX (iMac)

Comment 12

[Flore Allemandou [:flore]]

Also in the about:config on my Mac, values are different from windows:
gfx.content.azure.backends = skia
gfx.canvas.azure.backends = skia

That is their default value.

Comment 13

[Lee Salzman [:lsalzman]]

I did a preliminary investigation of this, and it does not seem to be a result of any simple changes that were made to DrawTargetSkia during the update to Skia m59. So the problem is more likely to be some deeper change/bug in Skia itself.

I was able to reproduce it on my Windows machine in one place. If you notice, on the line and nearby lines where it occurs, there is supposed to be a letter in the sentence that is underlined, but when this bug occurs, the letter is not. So I am guessing that for some reason or another this underline is positioned wrong, and that is the line we are seeing, but I have no hard evidence on this just yet.

I am on PTO till May 23, so I will resume looking into this then if nobody else figures it out before.

Comment 16

[Lee Salzman [:lsalzman]]

Attachment: fix premultiplied color output from linear gradients in Skia

This is a small bug with a loooong story.

What is noteworthy about these particular checkboxes is that they use linear gradients, and the color stops in these linear gradients have non-255 alpha values. This causes Skia to use a special path for unpremultiplied gradient colors when shading.

This path existed in the prior version of Skia, so it itself is not the cause of the bug. What is noteworthy is that Skia applies a small amount of dithering to the output pixels from the gradient shading. In the previous version, it always applied this dithering bias *before* the colors were premultiplied. In the new version of Skia, it tries to apply the bias *after* the colors are premultiplied.

This new code has a very subtle flaw. It uses Alpha*(1/255.0f) to make a scale factor to premultiply the color, to get around bad division performance. But Alpha*(1/255.0f) contains a small amount of scaling error that Alpha/255.0f would not. When then multiplied into the colors to premultiply them, this can cause the color values to subsequently round to integer values greater than the alpha, resulting in an invalid premultiplied color (i.e. R or G or B > A). This then causes downwind problems with displaying the invalid premultiplying color, showing up for us as black-ish instead of white-ish.

The input unpremultiplied color measured in situ was rgb 255 and alpha 246.9999. Once this gets premultiplied, we get rgb 247.0 and alpha 246.9999, which truncates to integer values rgb 247 and alpha 246.

So I came up with a small fix for this that should not impact performance. I measured the scaling error of Alpha*(1/255.0f) to be less than 1e-6 for all values of Alpha, so we just multiply the output alpha by 1 + 1e-6 so that it will get nudged upward like the colors are, thus they will all happily truncate to 247 this case and the error goes away.

Comment 17

[Lee Salzman [:lsalzman]]

Upstream Skia bug report: https://skia-review.googlesource.com/c/17818/

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4b9458e5d250
fix premultiplied color output from linear gradients in Skia. r=mchang

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/4b9458e5d250