Adds documentation for antialiasing with impeller - #13370
Conversation
|
Visit the preview URL for this PR (updated for commit 76cc499): https://flutter-docs-prod--pr13370-antialias-doc-17a96hc6.web.app |
andywolff
left a comment
There was a problem hiding this comment.
LGTM. Contents and location of the new doc make sense to me.
sfshaza2
left a comment
There was a problem hiding this comment.
Some smoothing out and one question for @gaaclarke.
|
Staged preview of the updated docs.flutter.dev site (updated for commit 06cfadf): https://flutter-docs-prod--docs-pr13370-antialias-doc-ukntvsmr.web.app |
|
Staged preview of the updated flutter.dev site (updated for commit 06cfadf): https://flutter-dev-230821--www-pr13370-antialias-doc-3m2qgc17.web.app |
sfshaza2
left a comment
There was a problem hiding this comment.
I know this is still in draft form, but this looks great, @gaaclarke! LGTM, for when you are ready to land.
|
@gaaclarke @flar Is this relevant as of 3.47? Is it ready to land? |
Yes it's relevant, please land it. |
There was a problem hiding this comment.
Code Review
This pull request introduces a new documentation page detailing Impeller's anti-aliasing techniques, specifically Multisample Anti-Aliasing (MSAA) and Signed Distance Fields (SDFs), and integrates it into the sidebar and the main Impeller documentation. The review feedback focuses on enhancing the clarity, grammar, and technical accuracy of the new page, including several suggestions for improved phrasing, formatting, and professional tone. Additionally, the reviewer requests clarification on whether the SDF configuration is iOS-only or if there is an equivalent setup for Android.
| Mobile phone GPUs have special hardware to optimize this process ( | ||
| [Tiled rendering][]). It comes in varying degrees of how many samples to | ||
| consider. |
There was a problem hiding this comment.
The line break inside the parentheses before the link [Tiled rendering][] is awkward. Adjusting the line break improves readability while adhering to the 80-character semantic line break limit.
| Mobile phone GPUs have special hardware to optimize this process ( | |
| [Tiled rendering][]). It comes in varying degrees of how many samples to | |
| consider. | |
| Mobile phone GPUs have special hardware to optimize this process | |
| ([Tiled rendering][]). It comes in varying degrees of how many samples to | |
| consider. |
| [Tiled rendering][]). It comes in varying degrees of how many samples to | ||
| consider. | ||
|
|
||
| On desktop and mobile 4x MSAA is used for all rendering calls. |
| Typically, hardware accelerated computer graphics define a series of points and | ||
| edges (a [mesh][]) and [shaders][]. Instead, SDF renders shapes in the fragment | ||
| shader program as signed distance fields. Since the shape is defined in the | ||
| fragment shader the edges can be smoothed at the fragment level instead of | ||
| relying on the rasterization of a mesh. |
There was a problem hiding this comment.
Improve clarity, grammar, and technical accuracy:
- Hyphenate "hardware-accelerated".
- Clarify "SDF renders" to "Impeller renders ... using signed distance fields (SDFs)" since SDF is the representation, not the renderer.
- Add a comma after the introductory conditional clause ("Since the shape is defined in the fragment shader,").
| Typically, hardware accelerated computer graphics define a series of points and | |
| edges (a [mesh][]) and [shaders][]. Instead, SDF renders shapes in the fragment | |
| shader program as signed distance fields. Since the shape is defined in the | |
| fragment shader the edges can be smoothed at the fragment level instead of | |
| relying on the rasterization of a mesh. | |
| Typically, hardware-accelerated computer graphics define a series of points and | |
| edges (a [mesh][]) and [shaders][]. Instead, Impeller renders shapes in the | |
| fragment shader program using signed distance fields (SDFs). Since the shape is | |
| defined in the fragment shader, the edges can be smoothed at the fragment level | |
| instead of relying on the rasterization of a mesh. |
| This technique is prioritized on desktop because SDF rendering puts more demand | ||
| on the GPU and Flutter supports older mobile phones. Also, the physical pixel | ||
| sizes on desktop computers are typically bigger than those of mobile phones. So | ||
| any imperfection will be more evident there. |
There was a problem hiding this comment.
Refine the phrasing for a more professional and technical tone:
- Use "places higher demands on" instead of "puts more demand on".
- Use "larger" instead of "bigger" for pixel sizes.
- Avoid starting a sentence with "So" in technical documentation; combine the clauses to improve flow.
| This technique is prioritized on desktop because SDF rendering puts more demand | |
| on the GPU and Flutter supports older mobile phones. Also, the physical pixel | |
| sizes on desktop computers are typically bigger than those of mobile phones. So | |
| any imperfection will be more evident there. | |
| This technique is prioritized on desktop because SDF rendering places higher | |
| demands on the GPU, and Flutter supports older mobile phones. Also, the physical | |
| pixel sizes on desktop computers are typically larger than those of mobile | |
| phones, making any imperfections more noticeable. |
| do so with the [FragmentShader API][]. Using the [drawPath()][] is sufficient | ||
| for most use cases without resorting to high quality SDF rendering. Not all | ||
| drawn paths are guaranteed to result in SDF rendering though. |
There was a problem hiding this comment.
Improve phrasing and grammar:
- Remove the unnecessary article "the" before
[drawPath()][]. - Hyphenate "high-quality" when used as a compound adjective.
- Avoid ending the sentence with "though" to maintain a professional tone.
| do so with the [FragmentShader API][]. Using the [drawPath()][] is sufficient | |
| for most use cases without resorting to high quality SDF rendering. Not all | |
| drawn paths are guaranteed to result in SDF rendering though. | |
| do so with the [FragmentShader API][]. Using [drawPath()][] is sufficient | |
| for most use cases without resorting to high-quality SDF rendering. However, | |
| not all drawn paths are guaranteed to result in SDF rendering. |
| ### Enabling SDFs on iOS | ||
|
|
||
| SDFs can be enabled on iOS by adding a new field to the `Info.plist` for the | ||
| project. |
There was a problem hiding this comment.
|
@gaaclarke, there are a number of suggested changes from Jim G. Can you address? |
gaaclarke
left a comment
There was a problem hiding this comment.
@flar I accepted wording updates, also fixed misleading text about MSAA, things that were a bit subjective or went into a higher level of detail than what was originally there I left out. Those might be better as a follow up PR from you so there is something more concrete to review.
done, thanks |
|
There is a bug in the precheck, the failure is saying the simple_sdf site is a 404 but it is declared as such: But the test is resolving it as |
|
Looks like that variable was removed sometime between the author of the PR and now, updated. |
|
Excellent! Thanks so much, @gaaclarke! |
This PR should only be landed after macOS impeller is switched to SDFs by default: flutter/flutter#183045
Description
This explains SDF rendering for macOS and covers antialiasing in general. The main things to communicate is the escape hatch if people want to implement their own SDFs and how to opt-in to SDFs on mobile devices.
Issues fixed by this PR
flutter/flutter#183043
PRs or commits this PR depends on
flutter/flutter#183045
Presubmit checklist
of 80 characters or fewer.