[ui] hold a strong reference to fragment program objects.

[jonahwilliams]

The native engine needs to hold a strong reference to fragment programs. So the dart side holding a weak ref is more or less pointless

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[jonahwilliams]

Lets see if any tests fail.....

[jonahwilliams]

they did not.

[dnfield]

This fixes flutter/flutter#141490 right?

[dnfield]

I wonder if this also breaks some programs out there? For example, I think the following used to work but now wouldn't:

1. Load a fragment program.
2. Get the shader, set some uniforms using setFloat.
3. Render.
4. Drop all references to the fragment program. Load it again.
5. Uniforms are not zeroed out now because of (2).

[jonahwilliams]

But the fragmentShader has the uniforms, not the program

[dnfield]

Ok. I thought I saw this but we can fix it separately if it's an issue.

I think a test should be possible for this, e.g. load FragmentProgram.fromAsset twice and make sure they objects are identical. Although that doesn't encode whether it's weakly or strongly held, and maybe for that we'd need a GC...

[jonahwilliams]

I added a test that checks if two loaded programs are identical, which at least verifies there is a cache. It can't verify the GC behavior obvs.