Initial linear gradient 4f impl

Initial linear gradient 4f impl

GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1688543002

Committed: https://skia.googlesource.com/skia/+/bc590c01b00ef79e1e1f30058e7a70a29419f2a9

[f(malita), 2016-02-09 23:24:03]

Description was changed from

==========
[WIP] FGradient
==========

to

==========
[WIP] FGradient
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[f(malita), 2016-02-18 18:37:29]

Description was changed from

==========
[WIP] FGradient
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
[WIP] 4f linear gradient impl

GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[f(malita), 2016-02-18 19:24:11]

fmalita@chromium.org changed reviewers:
+ herb@google.com, mtklein@google.com, reed@google.com

[f(malita), 2016-02-18 19:24:12]

This isn't ready for prime time, but the core logic should be reviewable. 
Looking for advice on how to improve the template structure.

What works:

  * native shading for both PM4f & PMColor paths
  * all tile modes
  * perf looks good (faster than current impl, particularly for kMirror or lots
of stops - see bench dump below)
  * gradient GMs look good, Blink diffs are sane

What doesn't:

  * perspective
  * GPU path
  * serialization, stringification & other boring stuff

typical ToT bench:

curr/maxrss	loops	min	median	mean	max	stddev	samples   	config	bench
  34/34 
MB	2	194µs	195µs	195µs	198µs	1%	▅█▃▇▂▁▄▁▃▁	8888	gradient_linear_clamp_shallow
  34/34 
MB	2	185µs	195µs	194µs	200µs	3%	█▆▇▆▇▆▇▁▃▁	8888	gradient_linear_clamp_shallow_dither
  34/34  MB	1	417µs	418µs	419µs	421µs	0%	▂▅▁▂▁▂█▁█▁	8888	gradient_linear_mirror
  34/34 
MB	2	190µs	194µs	197µs	209µs	4%	▆▆▆█▂▂▁▁▂▁	8888	gradient_linear_clamp_3color
  34/34 
MB	2	339µs	365µs	380µs	476µs	11%	▂▂▅█▄▂▂▃▁▁	8888	gradient_linear_clamp_hicolor
  34/34  MB	3	167µs	169µs	169µs	175µs	1%	▃▂▃▁▃█▂▃▁▃	8888	gradient_linear_clamp


typical 4flinear bench:

curr/maxrss	loops	min	median	mean	max	stddev	samples   	config	bench
  34/34 
MB	2	179µs	180µs	181µs	183µs	1%	▃▃▂█▁▇▁▆▂▆	8888	gradient_linear_clamp_shallow
  34/34 
MB	3	170µs	172µs	174µs	184µs	3%	▆█▁▂▂▁▂▁▂▂	8888	gradient_linear_clamp_shallow_dither
  34/34  MB	3	165µs	174µs	173µs	181µs	3%	▅▅█▄▅▅▅▅▂▁	8888	gradient_linear_mirror
  34/34 
MB	3	172µs	174µs	173µs	175µs	1%	▇█▂▆▅▂▅▁▄▃	8888	gradient_linear_clamp_3color
  34/34 
MB	2	275µs	284µs	286µs	314µs	5%	▄▄▁█▁▃▁▅▁▁	8888	gradient_linear_clamp_hicolor
  34/34  MB	3	150µs	157µs	160µs	190µs	7%	▃▂▂▂▂▂▂▃▁█	8888	gradient_linear_clamp

[reed1, 2016-02-18 20:02:45]

do you think the span/iterator pattern will apply to other gradient types (e.g.
radial), or is it just for linear?

[f(malita), 2016-02-18 20:12:18]

On 2016/02/18 20:02:45, reed1 wrote:
> do you think the span/iterator pattern will apply to other gradient types
(e.g.
> radial), or is it just for linear?

Yeah, that's the plan - but I'm not sure that I've split the logic correctly
(actually I'm pretty sure I didn't), will have to see what happens when trying
it.

[herb_g, 2016-02-18 21:54:57]

I've looked over the inner loops, and the look good. Maybe we can have a video
chat so I can get the over all pattern.

[f(malita), 2016-02-19 18:49:13]

On 2016/02/18 20:12:18, f(malita) wrote:
> On 2016/02/18 20:02:45, reed1 wrote:
> > do you think the span/iterator pattern will apply to other gradient types
> (e.g.
> > radial), or is it just for linear?
> 
> Yeah, that's the plan - but I'm not sure that I've split the logic correctly
> (actually I'm pretty sure I didn't), will have to see what happens when trying
> it.


Rather than keep it in limbo, I relocated the iterator to Sk4fLinearGradient for
now.  We can always revisit/refactor later.

On 2016/02/18 21:54:57, herb_g wrote:
> I've looked over the inner loops, and the look good. Maybe we can have a video
> chat so I can get the over all pattern.

Yup, we can certainly do that.  I've also uploaded a version with more comments
to hopefully clarify the overall approach.

[reed1, 2016-02-19 19:46:15]

lgtm

[f(malita), 2016-02-22 03:41:05]

Description was changed from

==========
[WIP] 4f linear gradient impl

GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Initial linear gradient 4f impl

GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[f(malita), 2016-02-22 04:27:19]

The CQ bit was checked by fmalita@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-22 04:27:28]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1688543002/320001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1688543002/320001

[f(malita), 2016-02-22 04:32:43]

Refactored as a straight shader context, to be instantiated by the existing
SkLinearGradient class.  This means it inherits all the existing goodies (GPU
effect, serialization), and only needs to handle raster shading.

The legacy context will go away eventually, but for now the plan is to make
SkLinearGradient create either a legacy context or a 4f context conditionally
(depending on the dest color type/profile, etc).  At the moment that's not
feasible (dest color info is not plumbed to onCreateContext/contextSize), so
I've just hacked a private gradient flag and added a couple of GM flavors
exercising the new path: GM:gradient_many_stops_4f, GM:linear_gradient_tiny_4f.

[commit-bot: I haz the power, 2016-02-22 04:49:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-22 04:49:07]

Dry run: This issue passed the CQ dry run.

[reed1, 2016-02-22 13:32:08]

we're in a similar boat w/ the old and new bitmap shader. How to know which
subclass to instantiate...

One idea is that we add a 2nd createContext call to shader, and let the blitter
choose (since it knows more of the pipeline).

e.g.
Context* SkShader::createContextOptimizedFor4f(...)

[f(malita), 2016-02-22 14:08:58]

On 2016/02/22 13:32:08, reed1 wrote:
> we're in a similar boat w/ the old and new bitmap shader. How to know which
> subclass to instantiate...
> 
> One idea is that we add a 2nd createContext call to shader, and let the
blitter
> choose (since it knows more of the pipeline).
> 
> e.g.
> Context* SkShader::createContextOptimizedFor4f(...)

My first thought was to modify createContext/contextSize to also pass the device
info (or just the color type/profile) as part of ContextRec and then let shaders
decide what to optimize for.

Do you have a preference for one approach over the other?

[f(malita), 2016-02-22 17:11:45]

The CQ bit was checked by fmalita@chromium.org

[f(malita), 2016-02-22 17:11:46]

The patchset sent to the CQ was uploaded after l-g-t-m from reed@google.com
Link to the patchset: https://codereview.chromium.org/1688543002/#ps320001
(title: " ")

[commit-bot: I haz the power, 2016-02-22 17:11:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1688543002/320001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1688543002/320001

[commit-bot: I haz the power, 2016-02-22 17:12:35]

Description was changed from

==========
Initial linear gradient 4f impl

GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Initial linear gradient 4f impl

GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...

Committed:
https://skia.googlesource.com/skia/+/bc590c01b00ef79e1e1f30058e7a70a29419f2a9
==========

[commit-bot: I haz the power, 2016-02-22 17:12:36]

Committed patchset #17 (id:320001) as
https://skia.googlesource.com/skia/+/bc590c01b00ef79e1e1f30058e7a70a29419f2a9