[Impeller] Add support for ImageFilter.shader
Copy-pasta docs:
/// Creates an image filter from a [FragmentShader].
///
/// The fragment shader provided here has additional requirements to be used
/// by the engine for filtering. The first uniform value must be a vec2, this
/// will be set by the engine to the size of the bound texture. There must
/// also be at least one sampler2D uniform, the first of which will be set by
/// the engine to contain the filter input.
///
/// For example, the following is a valid fragment shader that can be used
/// with this API. Note that the uniform names are not required to have any
/// particular value.
///
/// ```glsl
/// #include <flutter/runtime_effect.glsl>
///
/// uniform vec2 u_size;
/// uniform float u_time;
///
/// uniform sampler2D u_texture_input;
///
/// out vec4 frag_color;
///
/// void main() {
/// frag_color = texture(u_texture_input, FlutterFragCoord().xy / u_size) * u_time;
///
/// }
///
/// ```
///
/// This API is only supported when using the Impeller rendering engine. On
/// other backends a [UnsupportedError] will be thrown. This error can be
/// caught and used for feature detection.
Fixes https://github.com/jonahwilliams/flutter_shaders/issues/34 Fixes https://github.com/jonahwilliams/flutter_shaders/issues/26 Fixes https://github.com/flutter/flutter/issues/132099
Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change).
If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review.
Changes reported for pull request #53490 at sha 77e290bf60ea68e885efd055f911062e3cf26884
Golden file changes are available for triage from new commit, Click here to view.
Changes reported for pull request #53490 at sha 5bb88247639ab6b9c2f31b8bc986a8d40a63cb12
This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again.
Golden file changes are available for triage from new commit, Click here to view.
Changes reported for pull request #53490 at sha eab80e0b77ec03efd191a23624712ba8c1faa81a
@flar had feedback that he'd like me to separate the ColorSource type from the Filter type, so I'll follow up with that next.
Golden file changes are available for triage from new commit, Click here to view.
Changes reported for pull request #53490 at sha eba4796bf22c9fded78d41774683e6ffad452669
From offline discussion @flar and I agree that this is more of a ColorFilter than an ImageFilter, as we cannot change the render bounds (except for flooding the clip).
To do an ImageFilter, we'd ideally have a means for the developer to specify the bounds transformation based on the input bounds (just a matrix isn't good enough). However, as the developer is writing Dart and the engine is running C++, we'd either need to hack together some sort of serializable DSL or else allow the engine to execute dart code on the raster thread (with some restrictions).
This will be explored in a latter patch.
This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.
This on hold indefinitely. Its also not really a color filter, and I'm concerned we're going to get stuck with bad semantics so I'm going back to the drawing board.
Okay, I had more thoughts about this:
- Its not a fully functional ImageFilter, because we can't control the bounds.
- Its not a color filter either, as exposing the input via a texture allows developers to sample from locations other than the current pixel.
As a compromise, I think we should stick with calling it an ImageFilter for now. Its kind of a secret third thing, but that would be difficult to express in the existing API without other intrusive changes that I don't think are worth it. We may find a good way to express the potential bounds transformations in the future.
We could also add a ColorFilter.shader, that would be required to use a more constrainted sampling technique that we could use for further optimizations.
Golden file changes are available for triage from new commit, Click here to view.
Changes reported for pull request #53490 at sha d61c68c2df05dd787635ab02da776e6976e6aa3e
From offline discussion, lets add a Matrix option to provide some means of transforming the input pixels.
Golden file changes are available for triage from new commit, Click here to view.
Changes reported for pull request #53490 at sha 2edae620a4751e920e93172f0ce06d97ace50139
NVM we're not going to do the matrix approach. Adding @gaaclarke for the impeller side of things
Golden file changes are available for triage from new commit, Click here to view.
Changes reported for pull request #53490 at sha 10e9e5975eee4d23e47f8b28197587f9002d833c