Modify SkBitmap::extractSubset() to respect opaqueness. The resulting subset

Modify SkBitmap::extractSubset() to respect opaqueness. The resulting subset
bitmap will always have the same opaqueness flag as the source bitmap.

BUG=439

[skyostil, 2012-01-10 11:53:02]

Review please?

[skyostil, 2012-01-12 17:50:31]

Tom, would you mind taking a look?

[TomH, 2012-01-12 18:08:09]

Nice test. LGTM.
We leave this in reed@'s todo queue for a TBR, though, since there's been
confusion about the semantics of isOpaque() in the past.

[reed1, 2012-01-12 18:24:05]

lgtm

[bsalomon, 2012-01-12 18:24:06]

On 2012/01/12 18:08:09, TomH wrote:
> Nice test. LGTM.
> We leave this in reed@'s todo queue for a TBR, though, since there's been
> confusion about the semantics of isOpaque() in the past.

Do we want to do this with the volatile flag as well? I don't see a reason not
to.

[skyostil, 2012-01-13 15:16:14]

> Do we want to do this with the volatile flag as well? I don't see a reason not
> to.

I'll fix the volatility flag through
http://code.google.com/p/skia/issues/detail?id=452.

[TomH, 2012-02-07 18:12:40]

Has this landed? Do you need one of us to land it?

[reed1, 2012-02-07 18:15:56]

my read of the current sources is that this has landed (along with adding
setIsVolitile().

<starting at line 822>

    SkBitmap dst;
    dst.setConfig(this->config(), r.width(), r.height(), this->rowBytes());
    dst.setIsOpaque(this->isOpaque());
    dst.setIsVolatile(this->isVolatile());

    if (fPixelRef) {

[skyostil, 2012-02-07 18:18:05]

Yes, this has landed: http://code.google.com/p/skia/source/detail?r=3036. Looks
like I forgot to close the issue.

[TomH, 2012-02-16 21:22:23]

Bisection suggests that this may be the cause of
http://code.google.com/p/chromium/issues/detail?id=114107.