ITexturePreviewImages

Remarks

⚠ A picture and not a texture, and the reason is a Vulkan rule rather than a convenience. ShaderGraphPreviewRenderer's equivalent hands over a TextureViewHandle, because it draws its own targets on the graphics queue. A texture graph's images are written by TexturePlanEvaluator on ComputeQueue and every one of them is ResourceSharing.Exclusive — so reading one from the queue family the interface draws on, without a queue-family ownership transfer, leaves its contents undefined by specification. It would look perfect here: MoltenVK reports one family for both, and every adapter this engine is developed on does. It is the same mistake as #617 and #679, which is twice already.

So the pixels go through the host. TextureBake.Read already copies on the queue that wrote the image and hands back bytes; the host uploads those into a texture of its own, on its own queue, and answers with the number its image commands take. At Size squared that is sixteen kilobytes per node, which is a price worth paying to be right on a discrete card.

⚠ Public, and an InternalsVisibleTo naming the editor's own texturing plugin was the wrong answer — #1015. That is cheaper: two internal types, no guide page, no CheckApi baseline. It is also the arrangement ModuleReferenceTests exists to refuse, and it fired on the attempt — what a plugin reaches is reached through the public surface, because a friend assembly works for the one plugin this repository ships and for no third party. The shader graph's IPreviewImages is public one folder over for the same reason.

Methods (2)

• ulong Register(Bitmap picture, ulong existing)

  Names a picture, and returns the number to draw it by.

• void Release(ulong image)

  Gives up a number, because the node it belonged to is gone.

Used by (3)

• KeptVixen.Editor.TextureGraph.Tests
• TextureGraphPreviewsVixen.Editor.TextureGraph
• TexturePreviewImagesVixen.Editor.Texturing