[$500] Admins room summaries: chart/image font clarity is degraded (not sharp)

[melvin-bot]

Problem

The chart images shown in admins room summaries render at a lower resolution than the surrounding chat text — the fonts inside the charts look soft/blurry and are noticeably less sharp than native text in the chat.

Recorded from this chat: https://staging.new.expensify.com/r/5161784874458070

(Note: the original screen recording was further degraded by Snagit, but the sharpness gap is visible in-product.)

Expected

Chart images (and the text within them) should render at a crisp, high-DPI resolution that matches the clarity of the rest of the chat.

Related

• Chart→PNG rendering path: [Due for payment 2026-06-17] [Due for payment 2026-06-16] Create bun CLI to render Victory Charts to png #91528

Reported in Slack.

Issue Owner

Current Issue Owner: @abdulrahuman5196

[roryabraham]

@MelvinBot any theories on this?

[MelvinBot]

Issue Analysis

Root Cause: The chart PNGs are rasterized at 1× device-pixel-ratio (no supersampling). In renderChartToPng.tsx:35 the offscreen Skia surface is created at exactly the chart's logical size — makeOffscreenSurface(width, height) — where width/height come straight from the <victorychart> XML (default 600×400). So a 600×400-CSS chart becomes a 600×400-pixel PNG. When that image is displayed inline on a HiDPI screen (DPR 2–3), the browser upscales the raster to fill the layout box, softening the text — while the surrounding chat text is drawn at the display's real pixel density and stays crisp. That density gap is exactly the "soft/blurry chart fonts" being reported.

Recommended Fix: Render at an integer scale factor (e.g. SCALE = 2 or 3) so the PNG carries enough pixels to stay sharp when downscaled to its CSS box:

• Create the surface at width * SCALE × height * SCALE.
• Scale the canvas by SCALE before drawing so the chart's logical geometry (font sizes, radii, layout) is unchanged — only the pixel density increases. drawOffscreen doesn't expose a transform, but it's ~6 lines (headless/index.js); inline an equivalent that calls canvas.scale(SCALE, SCALE) between root.render(element) and root.drawOnCanvas(canvas).

This keeps the chart's on-screen size identical (consumers/emails still lay it out at 600×400) while quadrupling (at 2×) the rendered pixels, matching native text clarity.

Investigation details

• Pipeline: chart XML → CliVictoryChart (Victory → Skia) → offscreen Skia surface → image.encodeToBytes() → PNG. Nothing in the path applies a pixel ratio: grep -rn "pixelRatio|scale|dpr|devicePixel|resolution" server/victory-chart-renderer/src returns no scaling logic.
• CliVictoryChart is handed explicitSize = {width, height} and passes it to VictoryChartContainerFixed as the logical layout — the same numbers feed the Skia surface, confirming a strict 1:1 logical-to-pixel mapping.
• Alternative considered: font-rendering / antialiasing differences in headless Skia vs. in-product Skia. Possible secondary contributor, but it wouldn't explain a uniform sharpness gap that scales with the viewer's DPR — the 1× rasterization does, and it's the dominant factor.
• The original recording was additionally degraded by Snagit (per the issue), but the reporter confirms the gap is visible in-product, consistent with real upscaling rather than a recording artifact.
• Confidence: Medium-High — the 1× rasterization is confirmed in code; the "why it looks blurry" mechanism (HiDPI upscaling) is the standard cause but I inferred the display-side scaling rather than instrumenting the chat image element.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run

[roryabraham]

@MelvinBot this is occurring in-product, not in emails

[MelvinBot]

Correction to my earlier theory — and it narrows things down.

I traced the in-product live chart path end-to-end (victory-native → @shopify/react-native-skia → CanvasKit on web). The live renderer is DPR-correct: react-native-skia sizes the backing <canvas> at clientWidth × window.devicePixelRatio and scales the draw by DPR (SkiaPictureView.web.js onResize/draw), and App never forces it down — computeChartScale only ever scales down (a downscale supersamples, it can't cause upscale blur). So a live <victorychart> in a message renders crisp on a HiDPI screen.

That means the blurry charts you're seeing in-product are almost certainly embedded raster PNGs (<img>), not live charts — which is exactly the 1× rasterization I flagged before, just being displayed in-product rather than only in email. The pre-rendered chart PNG from renderChartToPng.tsx:35 is rasterized at the chart's logical size (makeOffscreenSurface(width, height), default 600×400) — 1× device pixels — so on a DPR 2–3 display the browser upscales it and the text goes soft, while surrounding DOM chat text stays sharp.

One decisive check settles it: open the message in that room and inspect the chart element in DevTools — is it an <img ...> (raster, the blur) or a <victorychart>/Skia <canvas> (live)?

• If it's an <img> PNG → root cause confirmed. Fixes: (a) render the PNG at 2–3× in the CLI (App-repo change), or (b) embed the chart as live <victorychart> XML in-product so the client renders it crisply. Which one the summary embeds is decided by the backend/concierge that composes the summary — outside the App repo — so the "image vs live XML" choice needs an internal engineer. Raising the PNG's DPI is the self-contained App-side fix.
• If it's a live chart → the softness is an inherent Skia/CanvasKit glyph-rasterization difference vs browser DOM text (grayscale AA, no subpixel), not a 1× bug, and would need a different approach.

Confidence: Medium — the live-renderer-is-crisp finding is high-confidence (traced in code), but I can't see that room's actual message payload, so I haven't confirmed the in-product chart is an <img>.

---

Next Steps: @MelvinBot <feedback> to refine, or confirm the DevTools check above and I can scope the PNG-DPI fix.

---

view run

[roryabraham]

@MelvinBot I'm pretty sure this chart is not an <img>. I don't think there's any code-path where charts render as images in-product: as far as I know that only happens in emails via the victory-chart-renderer binary.

[roryabraham]

I don't think Melvin will be much help here. We need to start with finding a consistent reproduction (the issue isn't very clear on that). Here's an example of what it looks like:

It's subtle but the text in the chart is less sharp than outside the chart.

Making this external. Any proposals should include minimal reproduction steps, plus a root-cause analysis and proposal to fix it.