The two DCHECKs in fast/backgrounds/zero-background-size.html, fast/backgrounds/size/zero.html appear to be working at ToT (r535096).  I filed  issue 809817  for fast/backgrounds/background-repeat-with-background-color.html.  I filed a number of issues that appeared for both gpu and oop raster in issue 809807.

Here's the classes of issues I ran into:


Red box instead of green:
 fast/backgrounds/background-clip-text-multiline.html

Weird clip path lines (only oop, not gpu):
 compositing/overflow/accelerated-scrolling-with-clip-path.html

Missing reflections:
 fast/reflections/reflection-masks-opacity.html
 fast/reflections/reflection-masks-outset.html
 fast/reflections/reflection-masks.html
 fast/reflections/reflection-with-zoom.html

Canvas broken?
 fast/canvas/ (many tests)
 fast/canvas/OffscreenCanvas* (many tests)

Image orientation missing images:
 fast/css/image-orientation/image-orientation-from-image-composited-dynamic.html
 fast/css/image-orientation/image-orientation-from-image-composited.html

Top middle shape is filled red when it shouldn't be:
 fast/replaced/border-radius-clip-content-edge.html

webgl images:
 fast/webgl/texImage-imageBitmap-from-blob-resize.html
 fast/webgl/texImage-imageBitmap-from-canvas-resize.html
 fast/webgl/texImage-imageBitmap-from-image-resize.html
 fast/webgl/texImage-imageBitmap-from-imageData-resize.html
 fast/webgl/texImage-imageBitmap-from-offscreen-canvas-resize.html
 fast/webgl/texImage-imageBitmap-from-video-resize.html

Deleted: background-repeat-with-background-color-actual.png 10.0 KB

	background-repeat-with-background-color-actual.png 10.0 KB View Download

Deleted: image-orientation-from-image-composited-dynamic-actual.png 38.2 KB

	image-orientation-from-image-composited-dynamic-actual.png 38.2 KB View Download

Deleted: border-radius-clip-content-edge-actual.png 14.9 KB

	border-radius-clip-content-edge-actual.png 14.9 KB View Download

border-radius-clip-content-edge also turns out to be a canvas failure

canvas failures seem likely to be  issue 806313 , in that oop raster doesn't know how to serialize the non-lazy bitmap canvas backing yet.

compositing/overflow/accelerated-scrolling-with-clip-path.html appears to be a swiftshader bug, potentially.  Moved to blocking issue 811513.

reflections seem to also be related to images writing an invalid transfer cache entry id (and then the op failing because of that).

I'm not quite sure why reflections are not using lazy images, but it's worth waiting until after the transfer cache handles non-lazy images before investigating too much further.

The bitmap patch fixes everything other that the first 2 from #1.

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

commit 3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda
Author: Adrienne Walker <enne@chromium.org>
Date: Tue Feb 13 23:49:40 2018

Simplify directly composited rotated images

Prior to this patch, if you had a directly composited 100x50 image and
it respected image-orientation: from-image, this resulted in:
* Blink decoding the image and rastering a bitmap with the rotation
baked in.  No image caching or ahead of time decoding.
* A PictureImageLayer with bounds 100x50 and a scale transform on that
layer of (0.5, 2.0, 1.0) which led to a contents scale of 2.0 (the max
scale) and a contents bounds of 200x100.
* An extra scale on the recording to squish the contents to the right
size.
* This path also didn't work in OOP because OOP doesn't support sending raw
bitmaps yet.

This simplifies the path to pass a matrix all the way through to the
resulting PictureImageLayer to handle the transformation at paint time
instead of decoding in Blink.  It also sets the bounds correctly on the
PictureImageLayer so no weird scales are needed for images from Blink.
Scales are still needed for masks however, because their bounds must
match the bounds of the layer they are masking.

An alternate path considered here was to not handle the rotation at
paint time and instead do it at compositing time, by baking the image
orientation into the layer transform.  However, because these transforms
can involve flips and layers can care about backface-visibility, this
has to be done at paint time to keep this layer's facing unchanged.

Bug: 809147
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ib6b275e8f7d47687336054c78772354ef8855a80
Reviewed-on: https://chromium-review.googlesource.com/912433
Commit-Queue: enne <enne@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536557}
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/cc/blink/web_image_layer_impl.cc
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/cc/blink/web_image_layer_impl.h
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/cc/layers/picture_image_layer.cc
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/cc/layers/picture_image_layer.h
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/cc/layers/picture_image_layer_unittest.cc
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/cc/trees/layer_tree_host_pixeltest_blending.cc
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/cc/trees/layer_tree_host_pixeltest_masks.cc
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/content/renderer/child_frame_compositing_helper.cc
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp
[modify] https://crrev.com/3178dcb77e71bb6fe589d06eadacf1fe2cfa9eda/third_party/WebKit/public/platform/WebImageLayer.h