Fix display list canvas not rendering correctly on high dpi displays

Fix display list canvas not rendering correctly on high dpi displays

The decision to use an intermediate rasterization buffer so that
the canvas can be renderered at the right resolution was be made
at record time in GraphicsContext::drawPicture. That code was unable
to determine whether the content would be further scaled by the
compositor, so it was often making the wrong decision. This change
uses a new option on SkPictureImageFilter to defer the decision
to playback time. This change also sets the filter level on the
SkPictureImageFilter, which solve the problem of respecting
the image-rendering:pexelated CSS style.

Note: the tests for issue 439251, which is fixed by this change,
are in a separate change that is still under review:
https://codereview.chromium.org/562583002/

BUG=439251, 432992
NOTRY=true

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=187187

[Justin Novosad, 2014-12-12 22:05:07]

junov@chromium.org changed reviewers:
+ senorblanco@chromium.org

[Justin Novosad, 2014-12-12 22:05:08]

PTAL

[Stephen White, 2014-12-12 22:10:38]

On 2014/12/12 22:05:08, junov wrote:
> PTAL

A	LayoutTests/fast/canvas/canvas-hidpi-blurry-expected.png

This shouldn't live in fast/canvas. If you want to check in a platform result
for the reviewer's benefit (thanks!), check it in to the correct platform
directory.

That said, IWBN if this could be made into a reftest instead.

[Stephen White, 2014-12-12 22:14:12]

https://codereview.chromium.org/799103002/diff/20001/Source/platform/graphics...
File Source/platform/graphics/GraphicsContext.cpp (right):

https://codereview.chromium.org/799103002/diff/20001/Source/platform/graphics...
Source/platform/graphics/GraphicsContext.cpp:571: void
GraphicsContext::compositePicture(SkPicture* picture, const FloatRect& dest,
const FloatRect& src, CompositeOperator op, WebBlendMode blendMode)
Why the name change? Most draw ops in GraphicsContext are called drawFoo(), even
if they also perform compositing.

https://codereview.chromium.org/799103002/diff/20001/Source/platform/graphics...
File Source/platform/graphics/ImageBuffer.cpp (right):

https://codereview.chromium.org/799103002/diff/20001/Source/platform/graphics...
Source/platform/graphics/ImageBuffer.cpp:268: RefPtr<SkPicture> picture =
m_surface->getPicture();
IWBN if the SkPicture-related stuff could all live in the surface, if possible,
and not be exposed at the ImageBuffer level.

Maybe we could have a draw(GraphicsContext* context, ...) virtual on
ImageBufferSurface? Just a thought.

[Justin Novosad, 2014-12-12 22:31:51]

Unfortunately, the test cannot be a ref test because there are no code paths in
the compositor that are guaranteed to always apply filtering in the same way
(ganesh vs sw skia vs direct OpenGL). Because of that, it is simplest if we stay
with a pixel test, which is easier to rebaseline than to have per-platform and
per virtual test suite -expected.html files.

https://codereview.chromium.org/799103002/diff/20001/Source/platform/graphics...
File Source/platform/graphics/GraphicsContext.cpp (right):

https://codereview.chromium.org/799103002/diff/20001/Source/platform/graphics...
Source/platform/graphics/GraphicsContext.cpp:571: void
GraphicsContext::compositePicture(SkPicture* picture, const FloatRect& dest,
const FloatRect& src, CompositeOperator op, WebBlendMode blendMode)
On 2014/12/12 22:14:11, Stephen White wrote:
> Why the name change? Most draw ops in GraphicsContext are called drawFoo(),
even
> if they also perform compositing.

Because the behavior is significantly different from the drawPicture just above,
which draw directly into the graphic context. This method, on the other hand,
draws into an intermediate buffer, so the picture gets composited as a whole (as
opposed to one primitive at a time).

https://codereview.chromium.org/799103002/diff/20001/Source/platform/graphics...
File Source/platform/graphics/ImageBuffer.cpp (right):

https://codereview.chromium.org/799103002/diff/20001/Source/platform/graphics...
Source/platform/graphics/ImageBuffer.cpp:268: RefPtr<SkPicture> picture =
m_surface->getPicture();
On 2014/12/12 22:14:12, Stephen White wrote:
> IWBN if the SkPicture-related stuff could all live in the surface, if
possible,
> and not be exposed at the ImageBuffer level.
> 
> Maybe we could have a draw(GraphicsContext* context, ...) virtual on
> ImageBufferSurface? Just a thought.

Acknowledged.

[Justin Novosad, 2014-12-13 02:18:14]

New Patch

[Stephen White, 2014-12-15 19:12:56]

LGTM

[Justin Novosad, 2014-12-15 19:34:54]

The CQ bit was checked by junov@chromium.org

[commit-bot: I haz the power, 2014-12-15 19:35:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/799103002/40001

[commit-bot: I haz the power, 2014-12-15 22:49:33]

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

[commit-bot: I haz the power, 2014-12-15 22:49:35]

Try jobs failed on following builders:
  mac_blink_rel on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/35600)

[Justin Novosad, 2014-12-15 22:54:27]

On 2014/12/15 22:49:35, I haz the power (commit-bot) wrote:
> Try jobs failed on following builders:
>   mac_blink_rel on tryserver.blink
>
(http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/35600)

SVG failures on mac_blink_rel are bot flake.  Using NOTRY to land

[Justin Novosad, 2014-12-15 22:54:34]

The CQ bit was checked by junov@chromium.org

[commit-bot: I haz the power, 2014-12-15 22:55:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/799103002/40001

[commit-bot: I haz the power, 2014-12-15 22:56:43]

Committed patchset #3 (id:40001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=187187