In the future, please just provide a screenshot when it clearly demonstrates the issue.

If the bisect here is correct, it's not japhet's change, it's likely the Skia roll.

bsalomon, as the TBR on that roll, could you check whether the Skia changes are responsible here so this can be assigned to an appropriate person?

I did a manual bisect and the winner is:

commit b4a7dc99b1a01cdd5c0cd5913b630436ca696210
Author: mtklein <mtklein@chromium.org>
Date:   Wed Mar 23 06:29:12 2016 -0700

    Port S32A_opaque blit row to SkOpts.
    
    This should be a pixel-for-pixel (i.e. bug-for-bug) port.
    
    BUG=skia:
    GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1820313002
    CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
    
    Review URL: https://codereview.chromium.org/1820313002


Visually it looks like it could be a SIMD alignment issue which comports with the above CL.

Deleted: badbuttons.png 3.2 KB

	badbuttons.png 3.2 KB View Download

 Issue 615978  has been merged into this issue.

There is no mtklein@chormium.org.

There is now.

Ah, the reputable Chormium browser project.

email_aliases++;

Looking at this now.

Also reproduces on Linux.

Ah, how very interesting!  Both the old code and the new code are correct.  The bug is that they're receiving invalid input, and it so happens that the SIMD-path and non-SIMD path happen to treat these invalid inputs differently.

In this case, we're drawing the background of the minimize, maximize and close buttons with the color 0x00ffffff, transparent white.  What's odd is this is making it through Skia as a premultiplied value.  0x00ffffff is not a valid premultiplied color... it should be 0x00000000.

With valid premultiplied pixels, there is no difference between
    uint32_t pixel = ...;
    if (pixel) { ... }
and
    uint32_t pixel = ...;
    if (pixel & 0xff000000) { ... }

That is, the only valid premultiplied color that has a top alpha byte of 0x00 is 0x00000000, so (pixel != 0) === ((pixel & 0xff000000) != 0).

This CL incidentally changed the portable code path from if (pixel & 0xff000000) to if (pixel); the SIMD code paths dealing with the 16-pixel strides happen to be doing the equivalent of (pixel & 0xff000000) both before and after this CL.

I'm going to do two things here, probably in two CLs:
   - restore the & 0xff000000 with a little note that it's not logically necessary but somehow in practice necessary;
   - add an assert that these pixels are premultiplied, which will fail, and see if I can track down where we went wrong.

The following revision refers to this bug:
  https://skia.googlesource.com/skia.git/+/3e3181263c034db3ba657c35cce9ae29c411b2b6

commit 3e3181263c034db3ba657c35cce9ae29c411b2b6
Author: mtklein <mtklein@chromium.org>
Date: Fri Jun 17 20:47:53 2016

Quick bandaid for chromium:611002.

We're somehow receiving non-premultiplied src inputs like 0x00ffffff to this
SrcOver blend.  That's a bug I intend to follow up on.  But for a quick
compatibility fix, go back to treating values like 0x00ffffff as transparent,
like we used to before crrev.com/1820313002.

This will not affect the correctness of code paths using properly premultiplied colors.

This should not change performance in any meaningful way.

The SIMD code paths (handling strides of 16 pixels at a time) happen to treat
invalid colors like 0x00fffff as transparent already.

BUG= chromium:611002 
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2075173002
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot

Review-Url: https://codereview.chromium.org/2075173002

[modify] https://crrev.com/3e3181263c034db3ba657c35cce9ae29c411b2b6/src/opts/SkBlitRow_opts.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/957af9b56d2d6531632426256bd8795a08157629

commit 957af9b56d2d6531632426256bd8795a08157629
Author: skia-deps-roller <skia-deps-roller@chromium.org>
Date: Fri Jun 17 23:28:38 2016

Roll src/third_party/skia/ e75cdcb85..802acec18 (4 commits).

https://chromium.googlesource.com/skia.git/+log/e75cdcb85b73..802acec1876b

$ git log e75cdcb85..802acec18 --date=short --no-merges --format='%ad %ae %s'
2016-06-17 egdaniel Revert of More removal of SkColorProfileType... (patchset #2 id:20001 of https://codereview.chromium.org/2071393002/ )
2016-06-17 hstern Fix mixup where SamplePathOverstroke wasn't added
2016-06-17 mtklein Quick bandaid for chromium:611002.
2016-06-17 brianosman More removal of SkColorProfileType...

BUG= 611002 

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
TBR=egdaniel@google.com

Review-Url: https://codereview.chromium.org/2076333002
Cr-Commit-Position: refs/heads/master@{#400541}

[modify] https://crrev.com/957af9b56d2d6531632426256bd8795a08157629/DEPS

Looks like that bandaid works fine.  The real fix is going to take longer... seems like there are several parts of Chrome feeding that function invalid input.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/220747df72f0024bb3438e350f2cef377367ef3d

commit 220747df72f0024bb3438e350f2cef377367ef3d
Author: mtklein <mtklein@chromium.org>
Date: Thu Jul 28 21:31:02 2016

CreateButtonBackground() has been creating unpremultiplied bitmaps.

This has been feeding unpremultiplied SkBitmaps into Skia as if they were premultiplied when drawing UI themes.  The attached bug shows an example of how this can go wrong.

It looks like this bug is ~7 years old.  While reading the code, I noted down a couple questions worth thinking about if we want to tread into this code again.

As it is, this should be enough to be able to revert the earlier bandaid CL I landed (see the bug).  It should also let us start asserting that premultiplied pixels are well-formed, to prevent this sort of problem in the future.

BUG= 611002 

Review-Url: https://codereview.chromium.org/2079413002
Cr-Commit-Position: refs/heads/master@{#408484}

[modify] https://crrev.com/220747df72f0024bb3438e350f2cef377367ef3d/ui/gfx/skbitmap_operations.cc