TextureHandle class final

A texture some backend owns, described in the engine's own vocabulary.

The type gpu.Texture used to be is the one that made resource management untestable: it cannot be constructed without a device, so every layer that merely held textures — the pool, the frame's resources — needed a running GPU to be exercised at all. This carries the description instead of the object, and keeps the object in backend where only the backend layer looks.

Identity is the contract

Deliberately no == or hashCode. Two places key on textures by identity and both would break under value equality:

• RenderTargetPool records what it has lent out. Two interchangeable textures have identical descriptions by definition — that is what makes them interchangeable — so value equality would make the pool believe it had lent one texture twice, and returning either would return both.
• FrameResources releases by identity, because a pass that writes the resource it read produces a second version standing on the same texture, and that texture goes back to the pool exactly once.

So: identical(a, b) must mean the same underlying texture, and one underlying texture must never acquire two handles. The second half is what createGpuTexture in gpu/gpu_texture.dart is for — it creates the texture and its one handle in the same expression, so no call site ever holds a bare backend texture it could wrap a second time.

Why the description is carried rather than asked for

The pool keys on exactly width, height, format, sampleCount and storageMode; the post passes read width and height to set a viewport. Every one of those would otherwise be a downcast to the backend type at the use site, which is the same coupling in a less visible place.