Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Need better, clearer image filter quality controls #76737

Closed
flutter/engine
#24797
Assignees
flar
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.
@yjbanov

Description

@yjbanov

(turning the discussion fromflutter/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 aFilterQuality enum value toPaint,ImageFilter.matrix, orTextureLayer (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 thanmedium when images are scaled down.

filter_quality

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

Proposals

SimplifyFilterQuality

Picking an enum value is quite simple. If the semantics of each value could be simplified theFilterQuality 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 behindhigh is confusing as it's good when scaling up, but worse thanmedium 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 tolow.

Add explicit sampling and mipmapping

For advanced use-cases we exposeSkSamplingOptions, 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


    [8]ページ先頭

    ©2009-2025 Movatter.jp