Support dithering gradients in the skia renderer

[wbk]

Notes

This overcomplicates brush_to_shader() a bit more than necessary to avoid duplicating two lines of code, but it made sense to me to pair shader-specific paint settings with shader-instantiation. One consideration is that brush_to_paint() already exists and has several callers in the renderer, but produces a Paint object that isn't compatible with colorize_image(). brush_to_shader() only has these two callers(one being brush_to_paint(), the other being colorize_image() so the complexity is mostly tucked away from the rest of the module.

Also, when trying this out with the energy monitor example, it seems to have traded banding in the background radial gradient for jitter in the background radial gradient. This doesn't make sense to me because dithering in skia is deterministic, but still seems like an improvement to me, and doesn't seem to affect linear gradients. Unsure if that's something idiosyncratic to the energy monitor, or to radial gradients.

[CLAassistant]

All committers have signed the CLA.

[ogoffart]

Thanks a lot for the patch!

The logic looks fine to me as far as i can see. Just made some style comments

[ogoffart]

If i'm not mistaken, this could be written

Suggested change

	.and_then(|shader| Some(func(paint, Some(shader))))
	.map(|shader| func(paint, Some(shader)))

[ogoffart]

This is a bit of a strangle pattern.
Why not having a function with this signature: brush_to_shader(...) -> Option(Paint, Shader) instead of taking a callback?
Then it can be used like so:

let (mut paint, shader) = Self::brush_to_shader(...)?;

Anyway it seems that the Shader cannot be None when the function is called, so no need to take an Option as argument.

[wbk]

Just personal preference, I felt like colorize_image was 2% clearer with the closure argument over a tuple return value, but I've been living mostly outside of rust lately and that was probably my being overly accustomed to foreign idioms.

Adjusted to match your feedback.

[wbk]

Edit: [disregard. you were right, this is better. fixup commit added]

Re: taking an Option as an argument, brush_to_paint() is more frequently referenced/called in the source and operates on an Option<shader>, so the cruft in colorize_ image(), to me, was simply picking favorites between the two callers (even though colorize suffers more than to_paint benefits). Happy to knock a ? from one and add a Some to the other if you find that preferable.

[ogoffart]

Thanks!