mlliu: This is the bug we discussed. Awesome that you can take a look at it!

[Bulk edit]

Setting tracking label Blimp-M53-Proj-Scope.  This label is for scope tracking purposes only and should not be added / removed from any bugs, even if we add additional bugs to M-53 scope, or remove this bug from M-53 scope.

+reed@

Note that the "magnifier" icon is white, but it has a blue background. So somehow the background color is missing so that the background is white instead and not able to see the "magnifier".

How i found that out.. 

I traced the mobile version of www.google.com with Frame Viewer on ContentShell.apk, and found that the image of the search button is missing in trace viewer. Dump the DisplayItemList to a SkPicture and opened it in skia debugger, and the button image is also missing (picture attached). The SkPicture is attached.

There is no separate layer for the button.

So the only thing that can explain this is, something wrong in SkPicture serialization. Because Blimp is serializing the SkPicture, but clank just copies the picture, while both Frame Viewer and the skia_debugger also serialize the SkPicture

@reed, should i file a separate bug for skia?

Deleted: image.png 22.3 KB

	image.png 22.3 KB View Download

Deleted: layer_0_content_shell.skp 53.8 KB

layer_0_content_shell.skp 53.8 KB Download

+mtklein, please look at #5

If anyone's eager to jump on this before I return on Monday, my first suspicion is the asymmetry between SkBinaryWriteBuffer::writeBitmap() and SkBinaryWriteBuffer::writeImage().  (SkBinaryWriteBuffer is the thing turning in-memory Skia objects into serialized bytes.)

writeBitmap() has several fallback modes and essentially cannot fail; writeImage() gives up pretty quickly if the pixel serializer doesn't know how to best encode an image.  We should be able to confirm this quickly by looking through the images section of the .skp, looking for that final 0 of failure (line 185).

This is not very urgent. Please update it when you figure it out after you return next week. thanks

friendly ping, mtklein@ do you have a chance to look into this?

Yes, I've started to look into this.

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

commit 96e4e1ca5a7dbe08b396817da30adfa3ecfd438c
Author: mtklein <mtklein@chromium.org>
Date: Thu Jun 09 17:38:08 2016

Add raw pixel serialization fallback for SkImages that cannot be encoded.

This fixes serialize-8888 for 2 GMs on Mac that I'm now unblacklisting.
I think another was already fixed, and two more were Windows-only.

Seems safe to use encoded_size=1 as another sentinel here (like we already
use =0); I can't imagine any encoded image format that can encode an image
in a single byte.

I suspect this is the root of the referenced bug too,
but this is a good idea even if not.

BUG= chromium:601851 
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2039813007

CQ_EXTRA_TRYBOTS=client.skia:Test-Win-MSVC-GCE-CPU-AVX2-x86_64-Release-Trybot,Test-Mac-Clang-MacMini6.2-CPU-AVX-x86_64-Release-Trybot;client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Release-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Release-Trybot

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

[modify] https://crrev.com/96e4e1ca5a7dbe08b396817da30adfa3ecfd438c/src/core/SkReadBuffer.cpp
[modify] https://crrev.com/96e4e1ca5a7dbe08b396817da30adfa3ecfd438c/src/core/SkWriteBuffer.cpp
[modify] https://crrev.com/96e4e1ca5a7dbe08b396817da30adfa3ecfd438c/tools/dm_flags.json
[modify] https://crrev.com/96e4e1ca5a7dbe08b396817da30adfa3ecfd438c/tools/dm_flags.py

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

commit 9e7131d291e547acc9a101672526cc5bd5c82f3d
Author: skia-deps-roller <skia-deps-roller@chromium.org>
Date: Thu Jun 09 20:30:45 2016

Roll src/third_party/skia/ 06ca8ec87..804b461bc (7 commits).

https://chromium.googlesource.com/skia.git/+log/06ca8ec87cf6..804b461bc4fe

$ git log 06ca8ec87..804b461bc --date=short --no-merges --format='%ad %ae %s'
2016-06-09 msarett SkPixmap::setColorSpace
2016-06-09 mtklein Add raw pixel serialization fallback for SkImages that cannot be encoded.
2016-06-09 mtklein Disable tail calls inside Simple GM functions.
2016-06-09 cblume SkMipMap::ComputeLevelSize should only cover SkMipMap's levels.
2016-06-09 brianosman Add control of manual mipmapping to GrContextOptions
2016-06-09 herb Simplify code by breaking general sampler into Nearest and Bilerp.
2016-06-09 mtklein better exclusion for stack traces

BUG= 601851 , 578304 

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

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

[modify] https://crrev.com/9e7131d291e547acc9a101672526cc5bd5c82f3d/DEPS

I just sync'ed my codebase to latest code. but looks like that CL doesn't resolve the bug :(

No prob, I'll keep digging at it.

Started digging through your .skp in the debugger.   I was confused.  There are no image serialization problems here that I can see.  The magnifying glass image is being drawn... it's just that the blue background of that button is not, so it's white on white.

It looks like we draw that button with:
   - ClipRRect     -- clip around the button to 38x40 bounds, appears to be a no-op but looks ok
   - DrawRect      -- fill the button, looks suspicious, see below
   - DrawRRect     -- draw the darker blue border around the button, looks ok
   - ClipRect      -- clip to the entire search bar and button, appears to be a no-op, but looks ok
   - DrawImageRect -- draw the magnifying glass, looks ok

As recorded in the .skp, what should be the operation that fills the button looks like this:

{
  "command": "DrawRect",
  "coords": [
    314,
    194,
    352,
    234
  ],
  "paint": {
    "antiAlias": true,
    "filterQuality": "low",
    "shader": {
      "data": "/data/5",
      "name": "SkEmptyShader",
      "values": {}
    }
  },
  "visible": true
}

The suspicious bit is that instead of a solid color, we've got a shader, and further, the shader is an SkEmptyShader... that won't draw anything.  This makes me think we've hit some fallback case of a shader that either cannot serialize itself or cannot be deserialized.

Here's what it's supposed to be in terms of CSS:

.lsbb {
    border-radius: 0;
    padding: 0;
    position: absolute;
    right: 0;
    top: 0;
    background-color: #4d90fe;
    box-sizing: border-box;
    -webkit-border-top-right-radius: 2px;
    background: -webkit-gradient(linear,left top,left bottom,from(#4D90FE),to(#4787ED)) !important;
    border: 1px solid #3079ed;
    height: 40px;
    width: 38px;
    -webkit-border-bottom-right-radius: 2px;
}

I wonder what shader that ends up as.  Presumably some SkLinearGradientShader, which should work just fine.

Just to rule out one unlikely answer, can you try again but building with
   CPPFLAGS=-DSK_ALLOW_CROSSPROCESS_PICTUREIMAGEFILTERS=1
?

If somehow Blink's making an SkPictureShader out of this gradient, then we may simply be refusing to serialize it.  Chromium by policy does not allow SkPictures to be deserialized in its main trusted process, and SkPictureShaders are a way to get an SkPicture into an SkImageFilter, which are sent from renderers to that trusted process.  But I would think that we'd still see it as an SkPictureShader, just with an empty SkPicture.  Anyway, that #define disables the policy, which will help us rule out that possibility.

ok. but i'm not sure where should i add CPPFLAGS=-DSK_ALLOW_CROSSPROCESS_PICTUREIMAGEFILTERS=1

is it a gn or gyp argument ?

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

commit 9e7131d291e547acc9a101672526cc5bd5c82f3d
Author: skia-deps-roller <skia-deps-roller@chromium.org>
Date: Thu Jun 09 20:30:45 2016

Roll src/third_party/skia/ 06ca8ec87..804b461bc (7 commits).

https://chromium.googlesource.com/skia.git/+log/06ca8ec87cf6..804b461bc4fe

$ git log 06ca8ec87..804b461bc --date=short --no-merges --format='%ad %ae %s'
2016-06-09 msarett SkPixmap::setColorSpace
2016-06-09 mtklein Add raw pixel serialization fallback for SkImages that cannot be encoded.
2016-06-09 mtklein Disable tail calls inside Simple GM functions.
2016-06-09 cblume SkMipMap::ComputeLevelSize should only cover SkMipMap's levels.
2016-06-09 brianosman Add control of manual mipmapping to GrContextOptions
2016-06-09 herb Simplify code by breaking general sampler into Nearest and Bilerp.
2016-06-09 mtklein better exclusion for stack traces

BUG= 601851 , 578304 

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

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

[modify] https://crrev.com/9e7131d291e547acc9a101672526cc5bd5c82f3d/DEPS

Bumping to M54, not a blocker on M53.

[Bulk edit]

Setting tracking label Blimp-M54-Proj-Scope.  This label is for scope tracking purposes only and should not be added / removed from any bugs, even if we add additional bugs to M-54 scope, or remove this bug from M-54 scope.

Moving to M55

Obsolete, WontFix.