Skip to content

Need better, clearer image filter quality controls #76737

@yjbanov

Description

@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.

filter_quality

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.

Metadata

Metadata

Assignees

Labels

P3Issues that are less important to the Flutter projecta: imagesLoading, displaying, rendering imagesa: qualityA truly polished experiencec: new featureNothing broken; request for a new capabilityc: proposalA detailed proposal for a change to Flutterengineflutter/engine related. See also e: labels.frameworkflutter/packages/flutter repository. See also f: labels.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions