{"version":"2.1.277","anchor":"ui-blit-now-distinguishes-raster-vs-image-sources","canonical_anchor":"plugin-ui-render-pipeline-gains-imageraster-component-resta","heading":"Plugin UI rendering adds an Image element alongside Raster","tier":"internal","area":"Plugin UI","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/ui-blit-now-distinguishes-raster-vs-image-sources","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Plugin UI rendering adds an Image element alongside Raster\n\nPlugin UI components can now draw and target an Image element, not just the existing Raster\/cell-based canvas\n\n**What**\n\n- The rendering diff\/restamp pipeline now handles a new `Image` element type alongside the existing `Raster`, with matching stamp\/seen-key\/refusal logic and an error when a render hook returns an image it didn't draw.\n\n- The `Image` render-props validator now accepts an optional `key` prop, which must be a non-empty string when present, and for images without columns\/rows or a resolvable source, it requires the image to be \"stamped by a plugin of this chain,\" otherwise reporting `Image \"<key>\" is not stamped by a plugin of this chain`.\n\n- The raster\/paint tool's input can now target an Image source directly, using `{ requestId, key, source }`, in addition to the existing cell-data form `{ requestId, key, cells }`.\n\n- `ui.blit` change detection now also treats a change in whether a `source` field is present or absent as meaningful, and its description now mentions \"the Raster or Image being blitted\" instead of just the Raster.\n\n**Why**\n\nThis lets plugins draw with a full image source rather than only an encoded grid of cells, while keeping the same ownership and stamping checks that stop one plugin from tampering with another plugin's drawing.\n\n- Area: Plugin UI\n- Names: `ui.blit`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}