[Impeller] Optimize the calculation of interpolant value of linear gradient

[ColdPaleLight]

Optimized the calculation method of t to avoid sqrt caused by calling the function length.

Pre-launch Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• I read the [Tree Hygiene] wiki page, which explains my responsibilities.
• I read and followed the [Flutter Style Guide] and the [C++, Objective-C, Java style guides].
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See [testing the engine] for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the [CLA].
• All existing and new tests are passing.

[chinmaygarde]

It would be great to have malioc traces of this.

[jonahwilliams]

I suspect we didn't get any malioc traces because there was no change in the statistics?

[ColdPaleLight]

Sorry, there are no malioc traces of this. This PR is purely from the level of code optimization.
The implementation of this PR is consistent with Skia.
https://github.com/google/skia/blob/main/src/sksl/sksl_graphite_frag.sksl#L392-L397

[auto-submit]

auto label is removed for flutter/engine, pr: 40085, due to - The status or check suite Linux Fuchsia FEMU has failed. Please fix the issues identified (or deflake) before re-applying this label.

[jonahwilliams]

Sorry, there are no malioc traces of this. This PR is purely from the level of code optimization.
The implementation of this PR is consistent with Skia.

We run malioc automatically on CI, so the fact that there was no test failure indicates that both this shader and the original compile to roughly the same code, at least for GLSL shaders

[ColdPaleLight]

Sorry, there are no malioc traces of this. This PR is purely from the level of code optimization.
The implementation of this PR is consistent with Skia.

We run malioc automatically on CI, so the fact that there was no test failure indicates that both this shader and the original compile to roughly the same code, at least for GLSL shaders

Ahh, I see. I ran malioc locally, and the result after the change is indeed the same as before. I guess it might be that the sqrt on the gpu is not as time consuming as I thought. Based on this fact, I think this PR can be closed.

[chinmaygarde]

@ColdPaleLight I think in this case, it could just be that the compiler applied the same optimizations you did. But this is again the ARM Mali Compiler and different compilers are different. We just use malioc to ensure we are making measurable improvements. But, sadly, we cannot measure everything everywhere. I still think this is a good optimization and its readable and maintainable. I'd vote to keep this in even if its a wash for malioc.

I'm glad you are considering shader quality and we could certainly use all the help we can get. This work will come in handy especially on Android. A quick introduction to reading malioc traces is here. An instance of measurable performance optimizations based on malioc traces is here. If you know of other ways of measurably improving shader quality, let's chat! We wired up malioc just as one way of giving us some guidance so there is less guesswork. There may be other better ways as well.

[ColdPaleLight]

@chinmaygarde Thanks for your information!