Update Ganesh to support fractional rects in drawBitmapRect

Update Ganesh to support fractional rects in drawBitmapRect

[bsalomon, 2012-09-28 13:13:18]

Overall this looks good. I just can't help but want to get rid of some of these
functions but maybe that needs some changes on canvas?

https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
src/gpu/SkGpuDevice.cpp:1243: 
It seems like the only thing preventing us from combining this with drawPLBmp is
that this guy is virtual with an IRect. Is it possible that we could (later)
remove drawBitmap as a virtual and make canvas call drawpBitmapRect with a i->s
conversion?

https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
src/gpu/SkGpuDevice.cpp:1318: this->drawLargeBitmap(draw, bitmap, srcRect, m,
params, &grPaint);
Maybe we can call this drawTiledBitmap... It just seems a little more precise
and consistent with shouldTileBitmap/determine_tile_size.

drawPLBmp -> drawBitmapCommon  (?)

or (I'm fishing here)

drawLPBmp -> internalDrawBitmap
internalDrawBitmap -> drawBitmapTile/drawBitmapSubrect
?

https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
src/gpu/SkGpuDevice.cpp:1363: SkRect srcR(tileR);
Do we need both tileR and srcR?

[robertphillips, 2012-09-28 17:13:56]

I could re-append drawTiledBitmap to drawBitmapCommon but I liked having them as
two screen sized functions rather than as one monster.

https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp
File src/gpu/SkGpuDevice.cpp (right):

https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
src/gpu/SkGpuDevice.cpp:1243: 
I believe that is Mike's plan for drawBitmap but for right now we are stuck with
this wrapper.

https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
src/gpu/SkGpuDevice.cpp:1318: this->drawLargeBitmap(draw, bitmap, srcRect, m,
params, &grPaint);
Done. Went with:

drawPLBmp -> drawBitmapCommon
drawLargeBitmap -> drawTiledBitmap
left internalDrawBitmap alone

I think this will make the most sense when the new drawBitmapCommon simply
becomes drawBitmap.

https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
src/gpu/SkGpuDevice.cpp:1363: SkRect srcR(tileR);
On 2012/09/28 13:13:19, bsalomon wrote:
> Do we need both tileR and srcR?

Done.

[bsalomon, 2012-09-28 17:22:22]

On 2012/09/28 17:13:56, robertphillips wrote:
> I could re-append drawTiledBitmap to drawBitmapCommon but I liked having them
as
> two screen sized functions rather than as one monster.
> 
> https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp
> File src/gpu/SkGpuDevice.cpp (right):
> 
>
https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
> src/gpu/SkGpuDevice.cpp:1243: 
> I believe that is Mike's plan for drawBitmap but for right now we are stuck
with
> this wrapper.
> 
>
https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
> src/gpu/SkGpuDevice.cpp:1318: this->drawLargeBitmap(draw, bitmap, srcRect, m,
> params, &grPaint);
> Done. Went with:
> 
> drawPLBmp -> drawBitmapCommon
> drawLargeBitmap -> drawTiledBitmap
> left internalDrawBitmap alone
> 
> I think this will make the most sense when the new drawBitmapCommon simply
> becomes drawBitmap.
> 
>
https://codereview.appspot.com/6561070/diff/2001/src/gpu/SkGpuDevice.cpp#newc...
> src/gpu/SkGpuDevice.cpp:1363: SkRect srcR(tileR);
> On 2012/09/28 13:13:19, bsalomon wrote:
> > Do we need both tileR and srcR?
> 
> Done.

LGTM

[reed1, 2012-09-28 17:53:15]

FWIW -- I'm completely fine with changes to device's virtual API, if that makes
things cleaner/clearer.

[robertphillips, 2012-09-28 18:07:10]

committed as r5724