Expand the gradient cache by 2 to store the min/max clamp values

Expand the gradient cache by 2 to store the min/max clamp values

This is a work-in-progress, but it'd be nice to get some feedback. The patch was originally done by Matt Woodrow a while ago, but I've been working on extending and rebasing it.

R=reed1
BUG=

[TomH, 2012-09-06 15:15:32]

Seems like a reasonable approach to me.

[reed1, 2012-09-06 16:28:36]

Feels like the right start, but we'll have to see the results.

1. the asABitmap dude needs to extractSubset() so it still returns a 256 width
bitmap (excluding the clamp values). I wonder if anything gets easier if the
clamped values are at [256] and [257], so that the base of the cache == the base
of the bitmap.

2. A more complete change is to re-scale the intermediate colors. With explicit
clamped values, we should be running our loops, not from [0 .. 1] but from
[1/512 .. 511/512]

3. What is the impact on existing gradients w/ this change? If it means a huge
rebaseline (for chrome at least) then we may need the change to be behind a
compile-flag for a while...

https://codereview.appspot.com/6496088/diff/1/src/effects/gradients/SkLinearG...
File src/effects/gradients/SkLinearGradient.cpp (left):

https://codereview.appspot.com/6496088/diff/1/src/effects/gradients/SkLinearG...
src/effects/gradients/SkLinearGradient.cpp:172: sk_memset32_dither(dstC,
Do we know that fV0 is always 0 in this case? Same for the fCount2 case below.

[gw280, 2012-09-06 18:04:50]

> 3. What is the impact on existing gradients w/ this change? If it means a huge
> rebaseline (for chrome at least) then we may need the change to be behind a
> compile-flag for a while...

I suspect this would require re-baselining. Is there an easy way to fire off a
Chromium try-bot for this?

>
https://codereview.appspot.com/6496088/diff/1/src/effects/gradients/SkLinearG...
> src/effects/gradients/SkLinearGradient.cpp:172: sk_memset32_dither(dstC,
> Do we know that fV0 is always 0 in this case? Same for the fCount2 case below.

What does fV0 represent here?

[reed1, 2012-09-06 18:07:53]

On 2012/09/06 18:04:50, gw280 wrote:
> > 3. What is the impact on existing gradients w/ this change? If it means a
huge
> > rebaseline (for chrome at least) then we may need the change to be behind a
> > compile-flag for a while...
> 
> I suspect this would require re-baselining. Is there an easy way to fire off a
> Chromium try-bot for this?
> 
> >
>
https://codereview.appspot.com/6496088/diff/1/src/effects/gradients/SkLinearG...
> > src/effects/gradients/SkLinearGradient.cpp:172: sk_memset32_dither(dstC,
> > Do we know that fV0 is always 0 in this case? Same for the fCount2 case
below.
> 
> What does fV0 represent here?

It represents the color value (either the first or last). Think about a gradient
that has a matrix that makes it go backwards. In that case, the left-most
clamped pixels will be the last color, not the first.

[reed1, 2013-05-01 18:33:04]

I have forgotten this one ... til now. Will revisit ASAP.

[TomH, 2013-06-03 11:20:31]

Ping.

[reed1, 2013-06-05 17:39:59]

What are the implications for the GPU backend, which gets the gradient
as-a-bitmap, and draws with that?

[TomH, 2014-12-22 23:26:51]

Pingedy ping ping ping - Mike, will your 64b work obsolete this?

[reed1, 2015-01-05 19:16:49]

I am treating this as abandoned, unless the author or someone else picks it up.