-
Notifications
You must be signed in to change notification settings - Fork 6k
Mark BackdropFilter as inheriting opacity, enabling fading of BDFs #34435
Conversation
CC @antholeole who was running into this issue recently |
I can confirm that this unblocks me! Thanks for the fix! This is awesome :) |
There's a bit of logspam, not sure if this is because I pulled your branch first and merged this over:
|
Haven't looked at the log spam mentioned above, but setting opacity on BDF layers is fine in Impeller. |
Thanks for checking! There should be a pre-check that maybe doesn't reject pushes, but indicates if there are new calls to FML_LOG in them. Actually, I don't see that any more. Were you running off the patch I sent for testing rather than the PR patch? |
Yep, you're right. I pulled but didn't rebuild, sorry about that. No logs in the most recent commit :) |
Customers have complained about BackdropFilter not working well with an enclosing OpacityLayer. This led to a bug in iOS dialogs from a few years back (see flutter/flutter#31706).
While this PR does not solve all cases where a BackdropFilter was nullified by being inside an enclosing saveLayer, it does solve a common case where the BackdropFilter is a direct (and only) child of an OpacityLayer.
Basically the fix is to mark the BackdropFilterLayer as able to inherit opacity which allows it to combine the opacity of a parent OpacityLayer into its own saveLayer.
Some refactoring of the AutoCachePaint facility was involved to more easily enable sharing of the object for both DisplayList and SkCanvas paths in the layers (as the 2 rendering variants of BackdropFilterLayer now need to do).