IEditorGraphics

Remarks

Doc 36 § F2's gap, found by the first plugin that draws. Until this, PluginServices published the project, the scene, the registries and the plugin host — and nothing device-shaped — so a third party could add a panel and could not put a picture in it. Editor/Vixen.Editor.Texturing is what found it and #737 is where it was reported.

⚠ Why this and not IGraphicsDevice straight into PluginServices, which is what #737 called "the smallest honest fix" — and why that one line could not have worked. EditorApplication builds its PluginHost in its constructor and does not have a device then: the host hands one over afterwards, through a settable property, and hands over again on the way down. PluginServices.Add throws on a second publish of a type, so there is no moment at which the device could have been added. What a plugin can be handed is therefore a live view of whether there is one — the same shape IActiveScene and IActiveView already take, and for the same reason.

⚠ And why the device is still handed over whole, rather than a narrower "allocate me a surface and run this on it". That was the intended answer and the evaluator refutes it: TexturePlanEvaluator caches a compiled pipeline per kernel and output format across evaluations, so a contract that lent the device for the duration of one call would make every preview recompile every kernel it had already compiled. A plugin that dispatches its own work needs a device it can hold, and nothing narrower expresses that.

⚠ What the plugin is promising by taking it. The device is the host's: it outlives every project, it is what the editor's own frame is recorded into, and IGraphicsDevice is IDisposable — a plugin that disposed it, or that called BeginFrame, EndFrame or CreateSwapChain on it, would take the editor down with it. Nothing here can prevent that; what this type does is make the loan the thing a plugin asks for by name, so the terms are written where the author reads them rather than inferred from a service that is simply a device.

⚠ Upload takes pixels rather than a texture view, and that is the deliberate half. A plugin's own image is created for whatever it dispatches into — TextureUsage.Storage, typically — and the interface renderer samples what it is given; a view registered straight from a storage image is missing TextureUsage.Sampled and is in the wrong layout, which MoltenVK forgives and a discrete card does not. The host already owns the three steps that make an upload correct — a staging buffer, a copy, and the two barriers — and doing them once, in the host, is what keeps that class of defect out of every plugin that draws.

Fields and properties (1)

• IGraphicsDevice? Device

  The device to allocate on and dispatch over, or null while this host has none.

Methods (2)

• IEditorImage? Upload(int width, int height, ReadOnlySpan<byte> rgba)

  Puts pixels where the interface can draw them.

• bool Update(IEditorImage image, int x, int y, int width, int height, ReadOnlySpan<byte> rgba)

  Rewrites one rectangle of a picture that is already on the screen.

Used by (17)

• EditorApplicationVixen.Editor.App
• EvaluatorDeviceChangeTestsVixen.Editor.Texturing.Tests
• GraphicsVixen.Editor.Texturing.Tests
• HolderVixen.Editor.App.Tests
• LayerStackPreviewVixen.Editor.Texturing
• MaterialBakeRouteVixen.Editor.Texturing
• PluginDeviceLossTestsVixen.Editor.App.Tests
• PluginGraphicsVixen.Editor.App
• PluginGraphicsTestsVixen.Editor.App.Tests
• RecordingGraphicsVixen.Editor.Texturing.Tests
• SwappingVixen.Editor.Texturing.Tests
• TextureGraphPreviewVixen.Editor.Texturing
• TexturePreviewVixen.Editor.Texturing
• TexturePreviewImagesVixen.Editor.Texturing
• TexturePreviewTestsVixen.Editor.Texturing.Tests
• TexturingFixtureVixen.Editor.Texturing.Tests
• TexturingModuleVixen.Editor.Texturing