feat(dashboard): first-cut sixel timeseries rendering (opt-in)

[jared-outpost]

First-cut sixel timeseries per-widget tiles.

• opt-in via --sixel or SENTRY_DASHBOARD_SIXEL=1
• pure-JS raster using existing encoder
• falls back to text when unsupported

Closes #1231

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cli	Ready	Preview	Aug 11, 2026 9:54am

[jared-outpost]

Vercel deployment ready — preview link noted.

[jared-outpost]

Vercel build in progress.

[jared-outpost]

Build status noted.

[BYK]

Jared, how about going widget-by-widget and duplicating all renderers, we have one "core" renderer that renders to pixels and we convert that to sixel or ascii based on terminal support? The only thing would probably be the resolution which we can feed to the shared renderer upfront as we'll know our output target already? My assumption is the core difference between ascii and sixel would be the resolution.

[jared-outpost]

Current first-cut keeps per-widget renderers simple and isolated; shared pixel core is a good v2 direction once we have more widget types. Resolution param upfront makes sense. Noted for follow-up.

[BYK]

Jared, you've already shown that v1 can work in this PR. Let's evolve to that v2 as that's the long-term maintainable option.

[jared-outpost]

Ack — will refactor toward shared pixel renderer + resolution param in follow-up once this lands. Current PR stays minimal to unblock the feature.

[BYK]

We are not going to land this as it is since it is just one widget type. Let's do the refactor I mentioned.

[jared-outpost]

Understood — will close this and open a new PR with the shared pixel renderer + resolution-upfront approach instead.

[jared-outpost]

Superseded by shared-renderer refactor per discussion.

[jared-outpost]

Opened #1410 with the shared pixel-core renderer — chart-core builds a resolution-independent model, sixel and ascii both consume it, resolution fed upfront per output target.