Fix LabelButtonBorder image blending.

Fix LabelButtonBorder image blending.

Use Skia's new SkLerpXfermode added for this purpose!
(linearly interpolates between src and dst image data)

Restore native style animation pre- http://crrev.com/199342
(paint background at full alpha, not 1-<animation alpha>)

Add support for Views Painters to use a custom SkPaint.
Move unfocused fallback to LabelButtonBorder::GetPainter.

BUG=239121, 155363
TEST=New button animations never let the background bleed through (see about:crash's reload button for an example).
R=reed@google.com,sky@chromium.org


Abandoned / On-Hold pending NativeTheme button painting.

[reed1, 2013-05-15 13:42:22]

brian (gpu backend lead) and I think a custom xfermode would be doable in the
shorter term. Not as efficient as a full-blown composit-shader, which we'd like
to do longer term, but should be as fast or faster than CreateBlendedBitmap.

https://code.google.com/p/skia/issues/detail?id=1295

[msw, 2013-06-12 19:30:31]

Hey Scott, please take a look; thanks!
Mike, can you check my xfer mode usage?

[reed1, 2013-06-12 20:05:09]

https://codereview.chromium.org/14921006/diff/14001/ui/views/controls/button/...
File ui/views/controls/button/label_button_border.cc (right):

https://codereview.chromium.org/14921006/diff/14001/ui/views/controls/button/...
ui/views/controls/button/label_button_border.cc:117:
canvas->SaveLayerAlpha(static_cast<uint8>(alpha));
Does this guy *not* actually create a layer if the passed alpha is 0xFF? ... I
hope so (for efficiency sake)

https://codereview.chromium.org/14921006/diff/14001/ui/views/controls/button/...
ui/views/controls/button/label_button_border.cc:124:
paint.setXfermode(SkLerpXfermode::Create(animation->GetCurrentValue()));
Create returns a new xfermode
setXfermode refs that mode (and will call unref when it dies)
... but we still have a dangling owner (Create), so we'll get a leak.

SkAutoTUnref<SkXfermode> mode(SkLerpXfermode::Create(...));
paint.setXfermode(mode);

The above will do the trick.

[msw, 2013-06-12 22:10:54]

Comments addressed, but now I'm seeing some awful remote behavior.
This worked great locally yesterday, but looks horrible now over RDP/CRD/NX.
Mid-animation, any button transparency is has black underneath; any ideas?
Should I do something else in remote desktop (non-accelerated?) conditions?

https://codereview.chromium.org/14921006/diff/14001/ui/views/controls/button/...
File ui/views/controls/button/label_button_border.cc (right):

https://codereview.chromium.org/14921006/diff/14001/ui/views/controls/button/...
ui/views/controls/button/label_button_border.cc:117:
canvas->SaveLayerAlpha(static_cast<uint8>(alpha));
On 2013/06/12 20:05:10, reed1 wrote:
> Does this guy *not* actually create a layer if the passed alpha is 0xFF? ... I
> hope so (for efficiency sake)

I think Canvas does create a layer for 0xFF, it seems equivalent to Save().
The underlying code just passes through to Skia's SkCanvas::saveLayerAlpha:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/skia/s...
This animation halts at full opacity and reverts to the simpler path below.

https://codereview.chromium.org/14921006/diff/14001/ui/views/controls/button/...
ui/views/controls/button/label_button_border.cc:124:
paint.setXfermode(SkLerpXfermode::Create(animation->GetCurrentValue()));
On 2013/06/12 20:05:10, reed1 wrote:
> Create returns a new xfermode
> setXfermode refs that mode (and will call unref when it dies)
> ... but we still have a dangling owner (Create), so we'll get a leak.
> 
> SkAutoTUnref<SkXfermode> mode(SkLerpXfermode::Create(...));
> paint.setXfermode(mode);
> 
> The above will do the trick.

I'm using skia::RefPtr instead; since SkAutoTUnref gives
** Presubmit ERRORS ** Banned functions were used.
      The use of SkAutoTUnref is dangerous because it implicitly
      converts to a raw pointer. Please use skia::RefPtr instead.

I found 2 other places using an SkXfermode::Create raw ptr:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/spe...
https://code.google.com/p/chromium/codesearch#chromium/src/ui/views/controls/...
Would you like me to file a bug? Should Create return a skia::RefPtr?

[reed1, 2013-06-13 13:27:43]

> Would you like me to file a bug? Should Create return a skia::RefPtr?

Better would be a chrome wrapper that does that for whatever factories it wants.

[sky, 2013-06-13 16:22:04]

https://codereview.chromium.org/14921006/diff/27001/ui/views/controls/button/...
File ui/views/controls/button/label_button_border.cc (right):

https://codereview.chromium.org/14921006/diff/27001/ui/views/controls/button/...
ui/views/controls/button/label_button_border.cc:112: ui::NativeTheme::State fore
= delegate->GetForegroundThemeState(&extra);
foreground, or fg.

https://codereview.chromium.org/14921006/diff/27001/ui/views/painter.h
File ui/views/painter.h (right):

https://codereview.chromium.org/14921006/diff/27001/ui/views/painter.h#newcode77
ui/views/painter.h:77: virtual void PaintWithSkPaint(gfx::Canvas* canvas,
Do we really need this?

[msw, 2013-06-13 17:29:49]

https://codereview.chromium.org/14921006/diff/27001/ui/views/painter.h
File ui/views/painter.h (right):

https://codereview.chromium.org/14921006/diff/27001/ui/views/painter.h#newcode77
ui/views/painter.h:77: virtual void PaintWithSkPaint(gfx::Canvas* canvas,
On 2013/06/13 16:22:04, sky wrote:
> Do we really need this?

The only alternative I see is exposing ImagePainter with this extra function.
Is there some way to set a Paint object on the canvas itself?

[msw, 2013-06-13 18:43:40]

Sorry for the wasted time here. I'm going to put this CL on hold while I work
towards painting the new button style through NativeTheme. As an aside, I'm
seeing the black fill of the transparent button areas locally too now. I have no
clue what I changed to cause this. :(