Need better, clearer image filter quality controls

[yjbanov]

(turning the discussion from flutter/engine#24582 into a feature request)

Our image filter quality controls could be clearer and give developers better control.

Background

Currently the only way to specify image filter quality is by passing a FilterQuality enum value to Paint, ImageFilter.matrix, or TextureLayer (docs). The enum provides 4 values: none, low, medium, high. These options do not always behave in accordance with their names. For example, high is often worse than medium when images are scaled down.

Mipmapping is only used for medium with undocumented sampling algorithm. There's no way to choose the scale sampling separately from mipmap sampling.

Proposals

Simplify FilterQuality

Picking an enum value is quite simple. If the semantics of each value could be simplified the FilterQuality could serve as a simple way to choose quality for simple use-cases. Currently this enum isn't as simple as it could be due to the aforementioned "high" vs "medium" inconsistency. We can provide more clarity with fewer options while covering most use-cases.

The values with useful semantics are:

• none - provides no quality enhancement, fast, useful for cases when the image is already pixel-perfect.
• low - provides some quality enhancement cheaply.
• medium - provides good quality.

The algorithm behind high is confusing as it's good when scaling up, but worse than medium when scaling down. We won't lose much if we removed this algorithm entirely.

What's left is to remap the enum value to the algorithms:

• low - provides no quality enhancement, fast, useful for cases when the image is already pixel-perfect.
• medium - provides some quality enhancement cheaply. This is the new default in the framework.
• high - provides good quality.

none is deprecated and maps to low.

Add explicit sampling and mipmapping

For advanced use-cases we expose SkSamplingOptions, which can express more advanced situations.

From @flar

If I'd get rid of any of the names I'd probably get rid of "none" as it is just such a bad name. It implies that nothing will happen if taken out of context and it falls out of the spectrum of "low/med/hi". I might have named it "fastest" or "lowest" originally, ignoring whether 3 or 4 constants are useful for Flutter apps.

[flar]

It would be helpful to include some down-scaling results for >0.5 When you go much below 0.5 then only mipmapping will help, but bicubic may show some reasonable results at less dramatic down-scales.

[yjbanov]

[flar]

If we add the Sampling options then we could/should probably just leave FilterQuality alone and document that it is equivalent to Sampling(..., ...) and explain the conditions in which it is better or worse than the other choices.

If we're not going to expose Sampling, then it might make sense to simplify FilterQuality, but I'm not sure it is all that useful if we just document it better. Would you basically map the values to?

• low - nearest neighbor
• medium - bilinear
• high - mipmap

If so, then that is a bit disruptive (everything just moves up a notch in the list) and would break all programs that specified a value manually.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.