Example program - the square is drawn as a texture and clicking the buttons requests the texture is redrawn in that color.

The example shows building a texture using FlPixelBufferTexture which is the higher level texture API. It might be worth using FlTextureGL (will require more boilerplate code) or both?

@cbracken Do you know how we decide what examples to support here? This seems like a reasonable thing to have an example of, but I don't know if there are specific criteria. (If we do want to do this, we should definitely have a plan for filling in the other platforms.)

We discussed a bit in yesterday's meeting. Now that https://github.com/flutter/samples exists, we should probably decide what to do with this directory altogether. These fall into two main categories:

• Sample code that is used to demonstrate some API/feature, typically in a fairly minimalistic way. However, in these cases we often inline the sample code right into e.g. a window controller, something we wouldn't encourage developers to do in real apps.
• Code that was a sample, but because it was handy to do so, we built integration tests on it, so the code now serves a sort of dual purpose. Things that were designed to be integration tests from the start are now located in dev/devicelab/integration_tests instead.

@redbrogdon @domesticmouse now that we have the flutter/samples repo, should the flutter/flutter examples directory even exist anymore? Do any of the samples in here make sense to move to flutter/samples? If not, perhaps we should move these to the devicelab integration tests directory?

There is at least one level on which this directory is different to the flutter/samples repo. This directory is maintained at head, whereas flutter/samples is mainly at stable. The other different is about who owns the code. I take no responsibility for maintaining what is here.

I'm just in the process of starting to tidy up the samples repo, looking to delete old cruft and think about what needs to be added. I'm unsure about taking on a bunch of new sample code while I'm paying down current tech debt.

The flutter examples/api directory definitely needs to continue to exist in the repo, at least.

@robert-ancell What is the intent of this sample: is it intended to be an example for how to use external textures, or is it meant to be more of a manual test for code in the repo? If it's the latter, we have a place for that in dev/manual_tests.

(Desktop Triage)

The intent is to be an example of how to use external textures.

IMO, putting it in the examples directory is fine. We can always move it out later if we change our minds: it's not part of the API.

Second PR is showing the same failures.

I think I've fixed the dependencies again as pointed out by @godofredoc. These constantly get out of sync with master. But the remaining build failures I can't see the issue - @godofredoc can you look again?

@reidbaker It looks like these CI failures might be caused by changes in: #125323

I'm not sure why this pull request is running into these issues, but it looks like there may be Gradle settings issues and ci.yaml tasks that need to be updated to JDK 17.

Spot checking https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8777565447134219249/+/u/run_test.dart_for_build_tests_shard_and_subshard_1_3/test_stdout

I seeWelcome to Gradle 7.5 but your new example does not define a gradle wrapper file so I think that is the host version of gradle. That said 7.5 should build.

The pr you linked I dont think can be rolled back. It was needed to support the latest google shipped tooling and I dont think these tests are failing on master.

It is possible that more tests need to be migrated to java 17. That pr was an attempt to get at least some testing migrated. I am not opposed to more (maybe even all?) of our testing migrated to java 17.

A guess at what might be happening here:
The distribution of the particular tests that are failing across shards is random, but with a fixed seed. So if the list of tests stays fixed, the distribution stays fixed. But this new example introduces a new item into the list, which means tests get re-distributed across shards.

This change made it so that some of the shards use jdk 17, while the rest use 11. This interacts with the tests in two ways:

1. Some of the tests are using very old versions of AGP (android gradle plugin). They have been running on a shard with jdk 11, and suddenly get kicked onto a shard with jdk 17 and start failing, because they don't support this newer jdk.
   (These are the tests failing with java.lang.reflect.InaccessibleObjectException: Unable to make field private final...)
2. Some examples are using AGP 8.0, which requires jdk 17. If they get kicked onto a shard running with jdk 11, they also start failing.
   (These are the tests failing with Android Gradle plugin requires Java 17 to run.)

If this is what is happening, it would be fixable by changing all the shards to use jdk 17, and upgrading all AGP versions in examples/ and integration_tests/ to >=7.3.0.

If this is what is happening, it would be fixable by changing all the shards to use jdk 17, and upgrading all AGP versions in examples/ and integration_tests/ to >=7.3.0.

The PR to do this was just merged, so if this was the cause updating the branch should hopefully fix the test failures!

It worked!! :)