{"version":"2.1.271","anchor":"new-raster-ui-component-type","canonical_anchor":"new-plugin-raster-component-for-terminal-canvas-painting","heading":"New 'Raster' component lets plugins paint to a terminal canvas","tier":"use","area":"Plugin UI","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271\/e\/new-raster-ui-component-type","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.271","markdown":"### New 'Raster' component lets plugins paint to a terminal canvas\n\nPlugins can now mount a 'Raster' element that paints pixel-like cell data directly onto the terminal\n\n**Unclear.** What content a 'Raster' component actually displays, and where it appears to users, is not stated.\n\n**What**\n\nA new `Raster` element type is available for plugins to use in their UI. It takes props like `{key, columns, rows, cells}`, where `cells` is base64-encoded packed cell data, and plugins can repaint it via a `paintRaster`-style call (`{ requestId, key, cells, columns, rows }`).\n\n- The rendering layer now sizes and lays out `Raster` elements like other UI primitives, and it participates in existing press\/hosted-button handling.\n\n- Global UI state now tracks `mountedRasters` (which rasters are currently mounted) and `rasterAdmission` (whether a raster is allowed to render).\n\n- Behind the scenes it includes an SGR-color cache, per-second blit (draw) throttling, and validation limited to BMP images with single-width cells.\n\n**Why**\n\nThis gives plugin authors a way to draw arbitrary pixel-like graphics into the terminal UI, beyond the text-based components available before, while the admission\/throttling logic keeps repeated repaints from overwhelming the terminal.\n\n- Area: Plugin UI\n- Names: `Raster`\n- Tier: Use it now\n- Useful: 4\/5\n- Signal: 3\/5\n- Present in the build but not switched on"}