Reimplement drawBitmapRectToRect to correctly handle fraction srcRect.
authorreed@google.com <reed@google.com@2bbb7eff-a529-9590-31e7-b0007b416f81>
Tue, 25 Sep 2012 15:37:50 +0000 (15:37 +0000)
committerreed@google.com <reed@google.com@2bbb7eff-a529-9590-31e7-b0007b416f81>
Tue, 25 Sep 2012 15:37:50 +0000 (15:37 +0000)
commit33535f3c48bf723c46f334a93d4a06d782dad30e
treed5dfb1ec904b1cf48fda20bdd194ffa66c170201
parent8640d5024d57da5508bdf7585849e3b1f1cb365b
Reimplement drawBitmapRectToRect to correctly handle fraction srcRect.

The prev impl relied on drawBitmap "deducing" the destination rect by applying
the computed matrix to the bitmap's bounds. This cannot be done if the srcRect
is fractional, and therefore not representable w/ a bitmap.

The new impl computes the same matrix, but calls down to the device via drawRect
+ a bitmap_shader. This allows us to specfiy the dstRect explicitly.

The possible down-side is that we now rely on the device subclass to efficiently
handle draRect+shader, instead of calling its drawBitmap entry-point.

To give the device the chance to handle this differently, I now call through to
a new device virtual: drawBitmapRect. The default impl is to create the shader
and call drawRect, but a subclass can intercept that.

For now, the GPU override of drawBitmapRect is mimicing the old behavior (by
rounding the srcRect to an iRect). This preserves its ability to call drawBitmap
which handles very-large textures, but shows some gittering/imprecision, due to
the rounding. ... this is the same GPU behavior we have before this CL.
Review URL: https://codereview.appspot.com/6542065

git-svn-id: http://skia.googlecode.com/svn/trunk@5663 2bbb7eff-a529-9590-31e7-b0007b416f81
include/core/SkDevice.h
include/gpu/SkGpuDevice.h
samplecode/SampleBitmapRect.cpp
src/core/SkCanvas.cpp
src/core/SkDevice.cpp
src/gpu/SkGpuDevice.cpp