Repository navigation
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the default anti-alias setting in DlPaint and Impeller's Paint to false (using DlPaint::kDefaultAntiAlias), aligning the default paint attributes with DlPaint::kDefault. It also adds documentation to DlOpReceiver regarding attribute initialization, updates existing tests to explicitly enable anti-aliasing where required, and introduces new unit tests to verify that initial paint states match DlPaint defaults. There are no review comments, and I have no feedback to provide.
|
This is simpler than the alternative PR, hopefully we won't see too many golden/scuba diffs. |
I'm expecting a ton of them. All our Impeller golden tests rely on the default DlPaint having AA=true. This changes the default to false. So all goldens on SDF backends will not use UberSDF anymore. We could change every test that declares a DlPaint to explicitly set it to AA=true. That's many hundreds of lines of changes though. I'm seeing if there's an easier more central change we could make. |
A bunch of changes for the SDF backend goldens, as expected: https://flutter-gold.skia.org/search?issue=193971&crs=github&patchsets=1&corpus=flutter I added commit c7c93ff, which is an attempt to make our golden tests default to DlPaint with AA=true without explicitly setting it in every test. It has a new Will wait and see if this eliminates all the golden changes once the tests finish. |
|
Another solution is to have the paint used for impeller dispatch default to AA=false. Impeller paint will default to true and the one we use for the dispatcher will just override that to false. |
|
dl_dispatcher.h line 67 - (move to dl_dispatcher.cc and) set the paint_.aa = false. |
We'd still need something like my |
|
With the |
|
Google testing finished. It has 3 failed tests, and none of them are related to this change. |
flar
left a comment
There was a problem hiding this comment.
I like the simplicity of the fix here, but I think we may be asking for trouble in how the unit tests are being changed to match the new default.
| /// impeller::testing::DefaultAntiAliasedDlPaint;`) so that the SDF playground | ||
| /// backends exercise the SDF path without every test opting in explicitly. | ||
| /// Only the default changes; setAntiAlias(false) works as usual. | ||
| class DefaultAntiAliasedDlPaint : public flutter::DlPaint { |
There was a problem hiding this comment.
I do like how this class reduces the number of changes needed to the unit tests, but I also feel that it is hiding a defaulting issue as it does so, especially with the way that many of the files use using DlPaint = ... as the way to deploy it. That hides what is going on and makes understanding the tests obscure. One concern is that test code gets copied a lot to make new tests and if someone creates the new test in a different file it might get a different definition of what "DlPaint" means without anything obvious to tip them off.
Some thoughts:
- Just bite the bullet and have all tests that need AA set it manually directly in the test.
- change to something more transparent in the test files such as
using DlPaintAA =orusing DlAAPaint =so that at least the tests that are using it have evidence that they are using the AA variant in their declaration.
There was a problem hiding this comment.
I think you're right that this makes understanding the tests a little obscure.
Changing to using DlPaintAA still requires changing every DlPaint instantiation to DlPaintAA, so it doesn't save us much compared to just explicitly calling paint.setAntiAlias(true) at every instantiation. And it still requires the DefaultAntiAliasedDlPaint class, which we don't need if we are just explicit with setAntiAlias.
I changed all the tests to explicitly use setAntiAlias. it's a lot of changed lines, but it's more clear about what is actually happening in the test. The downside to watch out for is that people may make tests in the future and might forget to explicitly set AA=true, so the test on the SDF backend will not actually test the SDF path.
There was a problem hiding this comment.
If we think this approach is the way forward, maybe I can make changing the tests a separate PR that I'll get merged first, so this PR will just be about changing the default value. What do you think?
| }; | ||
| // clang-format on | ||
| auto paint = flutter::DlPaint(flutter::DlColor::kDarkGrey()); | ||
| auto paint = DlPaint(flutter::DlColor::kDarkGrey()); |
There was a problem hiding this comment.
This is kind of an example of the obscurity. Someone might scratch their heads in the future wondering why this test now uses DlPaint directly whereas another test is using "flutter::DlPaint" and think it was just a change in policy regarding full naming, not realizing that the base name DlPaint is not the same as the qualified name "flutter::DlPaint"...
| : flutter::DlPaint(color) { | ||
| setAntiAlias(true); | ||
| } | ||
| // Implicit so that chained setters, which return flutter::DlPaint&, can |
There was a problem hiding this comment.
More obscurity and more workarounds to just having the unit tests simply initialize the AA flag as they desire.
flar
left a comment
There was a problem hiding this comment.
I like the explicit nature. Some of the paint objects probably don't need AA if they aren't going to be doing geometry fill/strokes, but they don't hurt anything.
At this point, does this seem advantageous compared to the other PR which switched all defaults (except Skia) to be AA=true?
| DisplayListBuilder builder; | ||
|
|
||
| builder.DrawPaint(DlPaint().setColor(DlColor::kWhite())); | ||
| builder.DrawPaint(DlPaint().setAntiAlias(true).setColor(DlColor::kWhite())); |
There was a problem hiding this comment.
cases like DrawPaint (and DrawColor) don't use the AA flag. Just FYI...
There was a problem hiding this comment.
In fact, these might be more easily expressed as calls to DrawColor anyway.
There was a problem hiding this comment.
As stated in my other comment, it seems simpler to me to change all DlPaint instantiations rather than go through them and determine whether we need an explicit AA=true for each case.
Changing DrawPaints to DrawColors is outside the scope of this PR.
Right, it doesn't hurt anything to set AA=true for calls which don't need it. But it seems like a lot of effort to look through every call case and determine whether we need it to set AA or not. And it increases the likelihood that someone in the future with copy/paste a test which doesn't set AA, but forget that their new test might need AA. It'll be a silent false positive golden for the SDF backend. So I think it's clearer to just always set AA=true for every paint, which matches with the default AA=true made by every call from dart:ui.
I don't know which I prefer. Maybe I prefer this default-false PR a little bit. This PR is a lot more boilerplate-verbose, and requires all new tests in the future to be slightly more verbose. But it preserves existing behavior better and more safely. The default-true PR would need to exhaustively track down all internal not-from-dart instantiations of DlPaint and explicitly set AA=false for them in order to maintain existing behavior (for Skia, at least). |
If we are okay with behavior changes, then I think I like the original default-true approach with no special casing for internal DlPaint instantiations. It means some small behavior changes for some cases on Skia, which we see in the google testing scuba goldens. The changes mean rendering is slightly different, but not incorrect and arguably more correct. If we're okay with that, I think that would be the best approach out of all the ones we considered. |
|
Closed in favor of the default true approach: #193939 |
The existing code has a mismatch with the default
isAntiAliasvalue of various initialPaintproperties used throughout the code.DisplayListBuilderuses a defaultDlPaint, which has a defaultisAntiAlias=false.DlSkPaintDispatchHelperuse a defaultSkPaint, which has a defaultisAntiAlias=false.DlOpReceivers use a defaultimpeller::Paint, which has a defaultisAntiAlias=true.The mismatch of
impeller::PaintandDisplayListBuilder'sDlPaintcauses issues.DisplayListBuilder'ssetAntiAliasno-op exits if setting the same value as its internalDlPaintstate:flutter/engine/src/flutter/display_list/dl_builder.h
Lines 277 to 281 in d454b1b
That works correctly if all its downstream
DlOpReceivers have matching initial values for theirPaintstate. But this is not the case forimpeller::Paint. If we get aPaintwithsetAntiAlias(false),DisplayListBuilderwon't pass this setting to its downstreamDlOpReceivers, instead incorrectly assuming that the downstream receivers already have a defaultfalsevalue.All of these defaults need to agree. We can either change them all to
trueor all tofalse. This changes them all tofalse.impeller::Paintis the only one that previously was default true, so it is the only one that changes. Note that this default is different from the defaultisAntiAlias=trueused fordart:ui'sPaint.kDefaultAntiAlias = falseconst toDlPaint, which it uses when initializing itself.impeller::Paintsets its default withDlPaint::kDefaultAntiAliasinstead of using atrueliteral. The default is nowfalseinstead oftrue, and is set to explicitly matchDlPaint's default.DlPainthaving AA=true to explicitly use AA=true (just SDF-related tests). Adds new tests to ensure the default paint inDlSkPaintDispatchHelperand the defaultimpeller::PaintmatchDlPaint.Fixes #193388
This is an alternate approach to #193939, which fixes the issue by aligning all the classes to use AA=true instead of AA=false. This AA=false better preserves existing behavior, because it does not change the value for engine-internal uses of
DlPaint(e.g.ShaderMaskLayer,RasterCache).Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
If this change needs to override an active code freeze, provide a comment explaining why. The code freeze workflow can be overridden by code reviewers. See pinned issues for any active code freezes with guidance.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.