Use GraphicContext::drawImageBuffer in FEBlend

Use GraphicContext::drawImageBuffer in FEBlend

Get rid of the "local" implementation of the blend modes in favor of the
Skia implementation.
Still uses the ARM NEON specific implementation for when
ARM_NEON_INTRINSICS is enabled.
Also change so that createImageFilter uses WebCoreCompositeToSkiaComposite
to map to the Skia Xfermode.

Inspired by WebKit commit http://trac.webkit.org/changeset/170433 by
Dirk Schulze.

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

[f(malita), 2014-07-24 16:23:49]

Nice cleanup, but I'm surprised we still care about the software filter path now
that deferred filters are enabled by default. I guess we still hit this for CSS
filters only?

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

https://codereview.chromium.org/416093002/diff/20002/Source/platform/graphics...
Source/platform/graphics/ImageBuffer.cpp:240: void
ImageBuffer::draw(GraphicsContext* context, const FloatRect& destRect, const
FloatRect* srcPtr, CompositeOperator op, blink::WebBlendMode blendMode)
I don't think the namespace selector is needed here.

https://codereview.chromium.org/416093002/diff/20002/Source/platform/graphics...
File Source/platform/graphics/filters/FEBlend.cpp (right):

https://codereview.chromium.org/416093002/diff/20002/Source/platform/graphics...
Source/platform/graphics/filters/FEBlend.cpp:80: return WebBlendModeNormal;
ASSERT_NOT_REACHED()?

https://codereview.chromium.org/416093002/diff/20002/Source/platform/graphics...
Source/platform/graphics/filters/FEBlend.cpp:131:
filterContext->drawImageBuffer(imageBuffer,
drawingRegionOfInputImage(in->absolutePaintRect()), 0, CompositeSourceOver,
blendMode);
Did you run some perf measurements by any chance? I'm somewhat concerned by two
blits vs. one pass before.

[fs, 2014-07-25 10:52:00]

>Nice cleanup, but I'm surprised we still care about the software filter path
now
>that deferred filters are enabled by default. I guess we still hit this for CSS
>filters only?

Yes, they're still used by one code-path AFAIK. Hopefully we can kick that last
code-path over soon though I hope.

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

https://codereview.chromium.org/416093002/diff/20002/Source/platform/graphics...
Source/platform/graphics/ImageBuffer.cpp:240: void
ImageBuffer::draw(GraphicsContext* context, const FloatRect& destRect, const
FloatRect* srcPtr, CompositeOperator op, blink::WebBlendMode blendMode)
On 2014/07/24 16:23:49, Florin Malita wrote:
> I don't think the namespace selector is needed here.

Dropped.

https://codereview.chromium.org/416093002/diff/20002/Source/platform/graphics...
File Source/platform/graphics/filters/FEBlend.cpp (right):

https://codereview.chromium.org/416093002/diff/20002/Source/platform/graphics...
Source/platform/graphics/filters/FEBlend.cpp:80: return WebBlendModeNormal;
On 2014/07/24 16:23:49, Florin Malita wrote:
> ASSERT_NOT_REACHED()?

Added.

https://codereview.chromium.org/416093002/diff/20002/Source/platform/graphics...
Source/platform/graphics/filters/FEBlend.cpp:131:
filterContext->drawImageBuffer(imageBuffer,
drawingRegionOfInputImage(in->absolutePaintRect()), 0, CompositeSourceOver,
blendMode);
On 2014/07/24 16:23:49, Florin Malita wrote:
> Did you run some perf measurements by any chance? I'm somewhat concerned by
two
> blits vs. one pass before.

I wrote a simple TC that filled the viewport w/ reasonably sized rectangle with
a blend-filter applied, and then cycled the fill of them in rAF-loop, and logged
the time between each rAF-callback. Ran it passing --disable-deferred-filters
(and --disable-gpu). This new code is actually slightly faster on my machine
(likely because of the SSE2-codepaths in Skia), so feel slightly less bad about
this now... The approximate timings I saw were:

w/ patch: ~85ms (jittery)
unpatched: ~100ms (jittery)

and for comparison:
deferred-filters: 50ms (fairly stable)

I guess the MIPS-people will be unhappy though =)

[f(malita), 2014-07-25 13:16:19]

On 2014/07/25 10:52:00, fs wrote:
> On 2014/07/24 16:23:49, Florin Malita wrote:
> > Did you run some perf measurements by any chance? I'm somewhat concerned by
> two
> > blits vs. one pass before.
> 
> I wrote a simple TC that filled the viewport w/ reasonably sized rectangle
with
> a blend-filter applied, and then cycled the fill of them in rAF-loop, and
logged
> the time between each rAF-callback. Ran it passing --disable-deferred-filters
> (and --disable-gpu). This new code is actually slightly faster on my machine
> (likely because of the SSE2-codepaths in Skia), so feel slightly less bad
about
> this now... The approximate timings I saw were:
> 
> w/ patch: ~85ms (jittery)
> unpatched: ~100ms (jittery)
> 
> and for comparison:
> deferred-filters: 50ms (fairly stable)

Awesome, thanks!

LGTM

[fs, 2014-07-25 14:47:46]

The CQ bit was checked by fs@opera.com

[commit-bot: I haz the power, 2014-07-25 14:48:38]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/fs@opera.com/416093002/70001

[commit-bot: I haz the power, 2014-07-25 15:32:56]

Change committed as 178936