HQ filtering for tiled/bleed drawBitmap

HQ filtering for tiled/bleed drawBitmap
sample at pix center in bicubic

Committed: http://code.google.com/p/skia/source/detail?r=12440

[bsalomon, 2013-11-27 20:52:10]

This makes HQ filtering work for drawBitmap on SkGpuDevice when bleeding outside
the src rect is allowed.

[jvanverth1, 2013-11-27 21:15:20]

lgtm + nits

https://codereview.chromium.org/83153006/diff/100001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

https://codereview.chromium.org/83153006/diff/100001/src/gpu/SkGpuDevice.cpp#...
src/gpu/SkGpuDevice.cpp:1366: SkASSERT(!bicubic);
indent

https://codereview.chromium.org/83153006/diff/100001/src/gpu/SkGpuDevice.cpp#...
src/gpu/SkGpuDevice.cpp:1412: effect.reset(GrBicubicEffect::Create(texture,
SkMatrix::I(), params));
indent

[Stephen White, 2013-11-27 21:50:06]

LGTM

https://codereview.chromium.org/83153006/diff/100001/include/gpu/SkGpuDevice.h
File include/gpu/SkGpuDevice.h (right):

https://codereview.chromium.org/83153006/diff/100001/include/gpu/SkGpuDevice....
include/gpu/SkGpuDevice.h:201: bool bicubic);
Not a big deal, but it seems a little weird that bicubic is special in this
case. Would it be worth it to pass SkPaint::FilterLevel through instead, and let
the internal funcs decide what to do with each level? Could be a bit more
self-documenting at the call sites than a bool, too.

[bsalomon, 2013-11-27 22:11:51]

https://codereview.chromium.org/83153006/diff/100001/include/gpu/SkGpuDevice.h
File include/gpu/SkGpuDevice.h (right):

https://codereview.chromium.org/83153006/diff/100001/include/gpu/SkGpuDevice....
include/gpu/SkGpuDevice.h:201: bool bicubic);
On 2013/11/27 21:50:06, Stephen White wrote:
> Not a big deal, but it seems a little weird that bicubic is special in this
> case. Would it be worth it to pass SkPaint::FilterLevel through instead, and
let
> the internal funcs decide what to do with each level? Could be a bit more
> self-documenting at the call sites than a bool, too.

We could. The reason I did the bool was that the FilterLevel has already been
partially digested by this point (to determine the GrTextureParams). That can't
be deferred because GrTextureParams is necessary to perform cache lookups
(thanks to the GPUs that don't support mipping or wrap modes for NPOT texutres).

[Stephen White, 2013-11-27 22:31:13]

https://codereview.chromium.org/83153006/diff/100001/include/gpu/SkGpuDevice.h
File include/gpu/SkGpuDevice.h (right):

https://codereview.chromium.org/83153006/diff/100001/include/gpu/SkGpuDevice....
include/gpu/SkGpuDevice.h:201: bool bicubic);
On 2013/11/27 22:11:51, bsalomon wrote:
> On 2013/11/27 21:50:06, Stephen White wrote:
> > Not a big deal, but it seems a little weird that bicubic is special in this
> > case. Would it be worth it to pass SkPaint::FilterLevel through instead, and
> let
> > the internal funcs decide what to do with each level? Could be a bit more
> > self-documenting at the call sites than a bool, too.
> 
> We could. The reason I did the bool was that the FilterLevel has already been
> partially digested by this point (to determine the GrTextureParams). That
can't
> be deferred because GrTextureParams is necessary to perform cache lookups
> (thanks to the GPUs that don't support mipping or wrap modes for NPOT
texutres).

Yeah, that's what I figured. Like I said, no big deal and still LGTM. :)

[commit-bot: I haz the power, 2013-12-02 14:56:53]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/bsalomon@google.com/83153006/120001

[commit-bot: I haz the power, 2013-12-02 15:06:23]

Retried try job too often on Build-Ubuntu12-GCC-x86_64-Release-Trybot for
step(s) BuildBench, BuildEverything, BuildGm, BuildTools
http://skiabot-master.pogerlabs.com:10117/buildstatus?builder=Build-Ubuntu12-...

[commit-bot: I haz the power, 2013-12-02 15:27:03]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/bsalomon@google.com/83153006/140001

[commit-bot: I haz the power, 2013-12-02 22:22:37]

Change committed as 12440