Adjust src and dest rects when drawing images instead of using a clip

Adjust src and dest rects when drawing images instead of using a clip

This patch removes a clip recorder in ImagePainter and VideoPainter
and simply adjusts the rects passed to GraphicsContext::drawImage. This
also fixes several tests using spv2 which were not applying the
spv1-only clip.

There's a minor resampling artifact on three tests which, regrettably,
must be turned into pixel tests.

BUG=627145
Committed: https://crrev.com/e7678ecd5f7c5bbdbfb78df2d8269a79e06236d4
Cr-Commit-Position: refs/heads/master@{#405033}

[pdr., 2016-07-11 17:59:22]

pdr@chromium.org changed reviewers:
+ chrishtr@chromium.org, fmalita@chromium.org

[pdr., 2016-07-11 18:02:44]

The CQ bit was checked by pdr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-11 18:02:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chrishtr, 2016-07-11 18:11:24]

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/TestExpectations (right):

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/TestExpectations:1381: crbug.com/627145
fast/css/object-fit-grow-landscape.html [ NeedsRebaseline ]
Please upload rebaselines on one platform for review.

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/paint/ImagePainter.cpp (right):

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.cpp:122: IntRect snappedDest =
pixelSnappedIntRect(destRect);
pixelSnappedDestRect

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/paint/ImagePainter.h (right):

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.h:26: // Paint the full image
into the dest, after clipping by the content rect.
"into |destRect|, after clipping by |contentRect|"

Also, it's unclear from context here what you mean by "paint into destRect", and
you should specify the coordinate space of these rects.

[f(malita), 2016-07-11 18:57:09]

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/paint/ImagePainter.cpp (right):

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.cpp:147:
context.drawImage(image.get(), snappedDest, &srcRect, SkXfermode::kSrcOver_Mode,
So previously we were always scaling/fitting the full image (srcRect* ==
nullptr) into dest, regardless of clipping.

But now, when the clip condition kicks in, we're no longer scaling the image but
extracting a subset and drawing 1:1.

^ looks like a potential functional change - is it intended and do we have any
test coverage for it?

[pdr., 2016-07-11 19:02:24]

On 2016/07/11 at 18:57:09, fmalita wrote:
>
https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
> File third_party/WebKit/Source/core/paint/ImagePainter.cpp (right):
> 
>
https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
> third_party/WebKit/Source/core/paint/ImagePainter.cpp:147:
context.drawImage(image.get(), snappedDest, &srcRect, SkXfermode::kSrcOver_Mode,
> So previously we were always scaling/fitting the full image (srcRect* ==
nullptr) into dest, regardless of clipping.
> 
> But now, when the clip condition kicks in, we're no longer scaling the image
but extracting a subset and drawing 1:1.
> 
> ^ looks like a potential functional change - is it intended and do we have any
test coverage for it?

(Still working on updating this patch for chrishtr's comment, but wanted to
reply to this)

I don't think this is a functional change in terms of scaling. Before, we'd just
paint offset + clip, whereas now we paint exactly the clip region. Does that
make sense, or do I misunderstand?

I do have a related question though--the new code goes down the different
drawImage codepath which results in a handful of pixel differences on two tests.
These pixel differences look random (e.g., they are in the center of the image
and not the borders, etc) and are probably just floating point differences in
Skia. Do you think these are a bug?

[f(malita), 2016-07-11 19:18:57]

On 2016/07/11 19:02:24, pdr. wrote:
> On 2016/07/11 at 18:57:09, fmalita wrote:
> >
>
https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
> > File third_party/WebKit/Source/core/paint/ImagePainter.cpp (right):
> > 
> >
>
https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
> > third_party/WebKit/Source/core/paint/ImagePainter.cpp:147:
> context.drawImage(image.get(), snappedDest, &srcRect,
SkXfermode::kSrcOver_Mode,
> > So previously we were always scaling/fitting the full image (srcRect* ==
> nullptr) into dest, regardless of clipping.
> > 
> > But now, when the clip condition kicks in, we're no longer scaling the image
> but extracting a subset and drawing 1:1.
> > 
> > ^ looks like a potential functional change - is it intended and do we have
any
> test coverage for it?
> 
> (Still working on updating this patch for chrishtr's comment, but wanted to
> reply to this)
> 
> I don't think this is a functional change in terms of scaling. Before, we'd
just
> paint offset + clip, whereas now we paint exactly the clip region. Does that
> make sense, or do I misunderstand?

So let's say the image is 100x100, the contentBox is 100x100 and the dest rect
is also 100x100

Previously, we would always scale/fit the full image into 100x100, regardless of
the clip => effective image scale always == 1.0

Now it looks like we're scaling depending on the intersection area.  Say they
only intersect in a quadrant (upper-right corner):

 * the intersection is 50x50
 * the src rect is now 50x50
 * dest rect is still 100x100
 * so we're drawing a 50x50 subset into a 100x100 dest
 => effective scale: 2.0

Maybe I'm missing something (are there invariants to prevent something like
this)?  Or should we also intersect the dest rect?

> 
> I do have a related question though--the new code goes down the different
> drawImage codepath which results in a handful of pixel differences on two
tests.
> These pixel differences look random (e.g., they are in the center of the image
> and not the borders, etc) and are probably just floating point differences in
> Skia. Do you think these are a bug?

It would be good to see the diffs, but minor middle-of-the-image variations are
usually just numerical artifacts due to different arithmetic.

[f(malita), 2016-07-11 19:34:34]

On 2016/07/11 19:18:57, f(malita) wrote:
> On 2016/07/11 19:02:24, pdr. wrote:
> > On 2016/07/11 at 18:57:09, fmalita wrote:
> > >
> >
>
https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
> > > File third_party/WebKit/Source/core/paint/ImagePainter.cpp (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
> > > third_party/WebKit/Source/core/paint/ImagePainter.cpp:147:
> > context.drawImage(image.get(), snappedDest, &srcRect,
> SkXfermode::kSrcOver_Mode,
> > > So previously we were always scaling/fitting the full image (srcRect* ==
> > nullptr) into dest, regardless of clipping.
> > > 
> > > But now, when the clip condition kicks in, we're no longer scaling the
image
> > but extracting a subset and drawing 1:1.
> > > 
> > > ^ looks like a potential functional change - is it intended and do we have
> any
> > test coverage for it?
> > 
> > (Still working on updating this patch for chrishtr's comment, but wanted to
> > reply to this)
> > 
> > I don't think this is a functional change in terms of scaling. Before, we'd
> just
> > paint offset + clip, whereas now we paint exactly the clip region. Does that
> > make sense, or do I misunderstand?
> 
> So let's say the image is 100x100, the contentBox is 100x100 and the dest rect
> is also 100x100
> 
> Previously, we would always scale/fit the full image into 100x100, regardless
of
> the clip => effective image scale always == 1.0
> 
> Now it looks like we're scaling depending on the intersection area.  Say they
> only intersect in a quadrant (upper-right corner):
> 
>  * the intersection is 50x50
>  * the src rect is now 50x50
>  * dest rect is still 100x100

^ This is wrong, I just noticed that dest rect gets intersected.  So please
disregard my concerns, I think the change is correct.


>  * so we're drawing a 50x50 subset into a 100x100 dest
>  => effective scale: 2.0
> 
> Maybe I'm missing something (are there invariants to prevent something like
> this)?  Or should we also intersect the dest rect?
> 
> > 
> > I do have a related question though--the new code goes down the different
> > drawImage codepath which results in a handful of pixel differences on two
> tests.
> > These pixel differences look random (e.g., they are in the center of the
image
> > and not the borders, etc) and are probably just floating point differences
in
> > Skia. Do you think these are a bug?
> 
> It would be good to see the diffs, but minor middle-of-the-image variations
are
> usually just numerical artifacts due to different arithmetic.

[commit-bot: I haz the power, 2016-07-11 19:40:18]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-11 19:40:19]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[pdr., 2016-07-11 19:41:55]

> > 
> > I do have a related question though--the new code goes down the different
> > drawImage codepath which results in a handful of pixel differences on two
tests.
> > These pixel differences look random (e.g., they are in the center of the
image
> > and not the borders, etc) and are probably just floating point differences
in
> > Skia. Do you think these are a bug?
> 
> It would be good to see the diffs, but minor middle-of-the-image variations
are usually just numerical artifacts due to different arithmetic.

Unfortunately this is a reftest so my newly uploaded results won't show a diff.
I've uploaded a copy of the diff for you at http://i.imgur.com/8O9SsCb.png

I agree that it's just minor floating point differences.

[f(malita), 2016-07-11 19:43:01]

lgtm

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/paint/ImagePainter.cpp (right):

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.cpp:137:
snappedContentRect.intersect(snappedDest);
Can the intersection be empty?  Should we bail in that case?

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.cpp:138: FloatRect
snappedBoundsInSrc = mapRect(snappedContentRect, snappedDest, srcRect);
Nit: snappedBoundsInSrc local doesn't add much value - assign directly to
srcRect?

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.cpp:139: srcRect =
snappedBoundsInSrc;
Nit: would this stick

DECHECK(image->rect().contains(srcRect));

[pdr., 2016-07-11 19:43:11]

On 2016/07/11 at 19:41:55, pdr. wrote:
> > > 
> > > I do have a related question though--the new code goes down the different
> > > drawImage codepath which results in a handful of pixel differences on two
tests.
> > > These pixel differences look random (e.g., they are in the center of the
image
> > > and not the borders, etc) and are probably just floating point differences
in
> > > Skia. Do you think these are a bug?
> > 
> > It would be good to see the diffs, but minor middle-of-the-image variations
are usually just numerical artifacts due to different arithmetic.
> 
> Unfortunately this is a reftest so my newly uploaded results won't show a
diff. I've uploaded a copy of the diff for you at http://i.imgur.com/8O9SsCb.png
> 
> I agree that it's just minor floating point differences.

Oh, there is another test failure that shows these differnces on the bot:
https://storage.googleapis.com/chromium-layout-test-archives/linux_chromium_r...

[f(malita), 2016-07-11 19:45:54]

On 2016/07/11 19:43:11, pdr. wrote:
> On 2016/07/11 at 19:41:55, pdr. wrote:
> > > > 
> > > > I do have a related question though--the new code goes down the
different
> > > > drawImage codepath which results in a handful of pixel differences on
two
> tests.
> > > > These pixel differences look random (e.g., they are in the center of the
> image
> > > > and not the borders, etc) and are probably just floating point
differences
> in
> > > > Skia. Do you think these are a bug?
> > > 
> > > It would be good to see the diffs, but minor middle-of-the-image
variations
> are usually just numerical artifacts due to different arithmetic.
> > 
> > Unfortunately this is a reftest so my newly uploaded results won't show a
> diff. I've uploaded a copy of the diff for you at
http://i.imgur.com/8O9SsCb.png
> > 
> > I agree that it's just minor floating point differences.
> 
> Oh, there is another test failure that shows these differnces on the bot:
>
https://storage.googleapis.com/chromium-layout-test-archives/linux_chromium_r...

Thanks.  Yeah, I wouldn't worry about something like that.

[pdr., 2016-07-11 19:58:17]

PTAL

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/TestExpectations (right):

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/TestExpectations:1381: crbug.com/627145
fast/css/object-fit-grow-landscape.html [ NeedsRebaseline ]
On 2016/07/11 at 18:11:24, chrishtr wrote:
> Please upload rebaselines on one platform for review.

Done.

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/paint/ImagePainter.cpp (right):

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.cpp:122: IntRect snappedDest =
pixelSnappedIntRect(destRect);
On 2016/07/11 at 18:11:24, chrishtr wrote:
> pixelSnappedDestRect

Done.

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.cpp:137:
snappedContentRect.intersect(snappedDest);
On 2016/07/11 at 19:43:00, f(malita) wrote:
> Can the intersection be empty?  Should we bail in that case?

I don't think so. Added a DCHECK to assert it.

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.cpp:138: FloatRect
snappedBoundsInSrc = mapRect(snappedContentRect, snappedDest, srcRect);
On 2016/07/11 at 19:43:00, f(malita) wrote:
> Nit: snappedBoundsInSrc local doesn't add much value - assign directly to
srcRect?

I renamed this pixelSnappedContentRectInSrc and refactored it to be used in the
DCHECK below. The compiler will optimize out any unneeded locals.

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
File third_party/WebKit/Source/core/paint/ImagePainter.h (right):

https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
third_party/WebKit/Source/core/paint/ImagePainter.h:26: // Paint the full image
into the dest, after clipping by the content rect.
On 2016/07/11 at 18:11:24, chrishtr wrote:
> "into |destRect|, after clipping by |contentRect|"

Done.

> 
> Also, it's unclear from context here what you mean by "paint into destRect",
and you should specify the coordinate space of these rects.

We talked about this offline but when I tried to do the refactoring to also pass
PaintOffset, I found it duplicated too much code. I've updated this comment to
say:
// Both |destRect| and |contentRect| should already be moved by the paint
offset.
This doesn't exactly answer the question about what coordinate space contentRect
is in though.

[pdr., 2016-07-11 20:30:00]

The CQ bit was checked by pdr@chromium.org to run a CQ dry run

[pdr., 2016-07-11 20:30:25]

Description was changed from

==========
Adjust src and dest rects when drawing images instead of using a clip

This patch removes a clip recorder in ImagePainter and VideoPainter
and simply adjusts the rects passed to GraphicsContext::drawImage. This
also fixes several tests using spv2 which were not applying the
spv1-only clip.

There's a minor resampling artifact on two tests which, regrettably,
must be turned into pixel tests.

BUG=627145
==========

to

==========
Adjust src and dest rects when drawing images instead of using a clip

This patch removes a clip recorder in ImagePainter and VideoPainter
and simply adjusts the rects passed to GraphicsContext::drawImage. This
also fixes several tests using spv2 which were not applying the
spv1-only clip.

There's a minor resampling artifact on three tests which, regrettably,
must be turned into pixel tests.

BUG=627145
==========

[commit-bot: I haz the power, 2016-07-11 20:30:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[pdr., 2016-07-11 21:09:20]

> > Also, it's unclear from context here what you mean by "paint into destRect",
and you should specify the coordinate space of these rects.

Updated this further, it is now:
// Paint the full image into |destRect|, after clipping by |contentRect|. Both
|destRect| and
// |contentRect| should be in local coordinates, plus offest by the paint
offset.

[pdr., 2016-07-11 21:09:28]

The CQ bit was checked by pdr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-11 21:09:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[chrishtr, 2016-07-11 22:14:44]

lgtm

[commit-bot: I haz the power, 2016-07-11 22:33:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-11 22:33:32]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[pdr., 2016-07-12 00:13:53]

The CQ bit was checked by pdr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 00:15:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[pdr., 2016-07-12 00:29:11]

On 2016/07/11 at 19:43:01, fmalita wrote:
> lgtm
> 
>
https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
> File third_party/WebKit/Source/core/paint/ImagePainter.cpp (right):
> 
>
https://codereview.chromium.org/2134253002/diff/1/third_party/WebKit/Source/c...
> third_party/WebKit/Source/core/paint/ImagePainter.cpp:137:
snappedContentRect.intersect(snappedDest);
> Can the intersection be empty?  Should we bail in that case?

This dcheck ended up firing.

We don't filter the content rect from what the user specifies like I thought.
I've updated this to bail as suggested.

[pdr., 2016-07-12 00:30:09]

The CQ bit was unchecked by pdr@chromium.org

[pdr., 2016-07-12 00:30:25]

The CQ bit was checked by pdr@chromium.org

[pdr., 2016-07-12 00:30:25]

The patchset sent to the CQ was uploaded after l-g-t-m from
fmalita@chromium.org, chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/2134253002/#ps60001
(title: "Bail if pixelSnappedContentRect.isEmpty(), like fmalita said we should
do")

[commit-bot: I haz the power, 2016-07-12 00:31:03]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-12 01:05:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-12 01:05:22]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[pdr., 2016-07-12 02:42:42]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2016-07-12 02:43:35]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[pdr., 2016-07-12 02:46:58]

The CQ bit was unchecked by pdr@chromium.org

[pdr., 2016-07-12 02:47:20]

On 2016/07/12 at 02:43:35, commit-bot wrote:
> CQ is trying da patch. Follow status at
>  
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

Was able to get the failing test to repro locally, investigating...

[pdr., 2016-07-12 02:57:27]

The CQ bit was checked by pdr@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 02:58:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[pdr., 2016-07-12 02:58:35]

This is another floating point issue.
benchmarks.benchmark_smoke_unittest.BenchmarkSmokeTest.service_worker.service_worker
has the following:
srcRect: 0.000000, 0.000000, 800.000000, 600.000000
contentRectInSrc: 0.000000, 22.950821, 800.000061, 553.005493

This asserts because the content rect is 0.000061 too large. BitmapImage::draw
already handles intersecting the src rect with the image rect, so I think we can
remove this DCHECK. I don't think it'll be useful to add a test specifically
covering this since it's just a floating point precision issue.

New patch uploaded, PTAL

[commit-bot: I haz the power, 2016-07-12 04:26:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-12 04:26:40]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[f(malita), 2016-07-12 16:48:48]

On 2016/07/12 02:58:35, pdr. wrote:
> This is another floating point issue.
>
benchmarks.benchmark_smoke_unittest.BenchmarkSmokeTest.service_worker.service_worker
> has the following:
> srcRect: 0.000000, 0.000000, 800.000000, 600.000000
> contentRectInSrc: 0.000000, 22.950821, 800.000061, 553.005493
> 
> This asserts because the content rect is 0.000061 too large. BitmapImage::draw
> already handles intersecting the src rect with the image rect, so I think we
can
> remove this DCHECK. I don't think it'll be useful to add a test specifically
> covering this since it's just a floating point precision issue.
> 
> New patch uploaded, PTAL

LGTM++

[pdr., 2016-07-12 19:28:31]

The CQ bit was checked by pdr@chromium.org

[pdr., 2016-07-12 19:28:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
chrishtr@chromium.org
Link to the patchset: https://codereview.chromium.org/2134253002/#ps80001
(title: "Remove dcheck for containment")

[commit-bot: I haz the power, 2016-07-12 19:33:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-12 22:38:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-12 22:38:39]

Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[pdr., 2016-07-12 22:53:14]

On 2016/07/12 at 22:38:39, commit-bot wrote:
> Try jobs failed on following builders:
>   linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

I think this was just another flake, see:
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium...

CQ again

[pdr., 2016-07-12 22:53:20]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2016-07-12 22:55:02]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 00:59:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-13 01:00:01]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[pdr., 2016-07-13 02:43:45]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2016-07-13 02:45:10]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 05:00:47]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-07-13 05:00:58]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-13 05:03:25]

Description was changed from

==========
Adjust src and dest rects when drawing images instead of using a clip

This patch removes a clip recorder in ImagePainter and VideoPainter
and simply adjusts the rects passed to GraphicsContext::drawImage. This
also fixes several tests using spv2 which were not applying the
spv1-only clip.

There's a minor resampling artifact on three tests which, regrettably,
must be turned into pixel tests.

BUG=627145
==========

to

==========
Adjust src and dest rects when drawing images instead of using a clip

This patch removes a clip recorder in ImagePainter and VideoPainter
and simply adjusts the rects passed to GraphicsContext::drawImage. This
also fixes several tests using spv2 which were not applying the
spv1-only clip.

There's a minor resampling artifact on three tests which, regrettably,
must be turned into pixel tests.

BUG=627145

Committed: https://crrev.com/e7678ecd5f7c5bbdbfb78df2d8269a79e06236d4
Cr-Commit-Position: refs/heads/master@{#405033}
==========

[commit-bot: I haz the power, 2016-07-13 05:03:27]

Patchset 5 (id:??) landed as
https://crrev.com/e7678ecd5f7c5bbdbfb78df2d8269a79e06236d4
Cr-Commit-Position: refs/heads/master@{#405033}