flutter
Use DlImageFilter for ImageFilterLayer
Now we can use DlImageFilter to replace SkImageFilter which can help us to enable some optimizations such as removing saveLayer objects for things like a matrix transform image filter on a compatible group of children.
@JsouLiang Are you interested in continuing with this PR? Moving to WIP since it sounds like @flar is requesting some bigger changes.
@JsouLiang Are you interested in continuing with this PR? Moving to WIP since it sounds like @flar is requesting some bigger changes.
That must have been a misunderstanding. There are no "bigger changes", this work is simply dependent on another mechanism being added under https://github.com/flutter/engine/pull/34878
There is something even more troubling about the DlAutoSaveLayer concept and even our existing DL-based saveLayers...
They aren't executed on the internal_nodes_canvas which means they aren't propagated to other embedding layer canvas objects. There is a lot more thought to be done on how we're managing the saveLayer stack in the presence of DisplayListBuilders that goes far beyond this PR. For now, just continue with the same paradigm of using leaf_nodes_builder.saveLayer in the builder pathways.
Sadly, it looks like this PR and the similar one for DlColorFilter introduced a bug. I haven't written any code to exploit it, but if we ever have a ColorFilterLayer or ImageFilterLayer that includes a PlatformView in its children then the filter will only apply to its pre-embedded children since we bypass the internal_nodes_canvas with the saveLayer calls. I think we have to revert the CF-de-skia-fying PR as well as hold off on this PR until we can come up with a new plan for how a post-Skia API world will deal with the stratifying of the layers due to embedded views. It isn't too hard to think "well, we can just convert everything to DisplayList and use a solution like https://github.com/flutter/flutter/issues/109563 to replace it" but such a solution would impact our rendering using the Skia backend greatly as we would then be recording the scene into a DisplayList and playing it back to Skia rather than direct rendering to Skia. Until Impeller is our default rendering backend we'll have to make sure that our solution to this problem doesn't impact the Skia backend.