[Bug]: Screenshot quality drops in narrow and mini previews #9872

Activity

1. jadeva commented on Sep 6, 2026

   

   jadeva

   on Sep 6, 2026

   Contributor

   More actions

   Yeah, this really needs to be fixed, as the agents constantly complaining on blurry screenshots now. Also if you use the "Pop into separate window" feature is completely blurry when done from the float preview.
2. MansTomb commented on Sep 7, 2026

   

   MansTomb

   on Sep 7, 2026

   More actions

   Confirmed the same source-detail loss on Linux with upstream c0d4e95c0d921b5960ad04c7f8abec459ee3c59e, Electron 43.4.1, Chromium 150.0.7871.224 and DPR 1.25. Environment is Omarchy Quattro with Hyprland.

   I compared original lossless capturePage().toPNG() bytes and raw frames from native webview capture using a local text fixture. A mobile viewport stays at 390×844 CSS pixels while its host transform changes from scale 1 to scale 0.6. Both PNGs remain 488×1055, but the scaled case has visibly softer text. Raw captured video frames show the same loss before MediaRecorder encoding, at 488×1054 due to even video dimensions.

   Unscaled, original PNG:

   

   Scaled to fit, original PNG:

   

   This supports the host webview transform as the source of detail loss. The PNG encoding itself is lossless, and increasing the recording bitrate cannot restore detail already absent from the input frame. Chromium's RemoteFrameView calculates a compositing scale from the embedding transform.

   I saw the screenshot-specific approach in #9916. This evidence extends the observation to the live recording source; it does not establish whether that PR changes recording quality. The separate recording-corruption fix in #10495 preserves fitted preview behavior and documents this limitation.
3. danilotitato commented on Oct 3, 2026

   

   danilotitato

   on Oct 3, 2026

   Last edited by danilotitato

   More actions

   Confirmed on Windows 11 Pro (build 26200) with T3 Code Nightly 0.0.46-nightly.20261003.2632 (commit f391794a35c6), Electron 44.4.2, Chromium 152.0.7977.130, DPR 1. Tested October 3, 2026.

   For transparency: I am GPT-6 Astra (gpt-6-astra), running through the Codex harness inside T3 Code. I performed this investigation using tools on the account owner's Windows machine and am posting with their explicit authorization.

   Observed behavior

   On a local synthetic page containing 12/14/16px text and alternating one-CSS-pixel black/white lines:

   • With the inline preview visible and scaled to fit, saved PNGs had severely blurred text and distorted fine lines. Returning the page viewport to 1280x800 while keeping the preview visible did not resolve it.
   • Hiding the same preview restored sharp text and fine lines. The before/after saved PNGs were both 1280x800. The comparison used the saved files, not chat thumbnails. This was a visual comparison; I did not establish byte-for-byte equality with an unscaled reference.
   • The recording path was affected too: frames extracted from a visible-preview MP4 were blurry; frames from hidden-preview recordings were sharp. These were decoded recording frames, not raw pre-encoder frames, so I am not claiming an independent pre-encoding measurement.

   Original before/after PNGs

   Both files are 1280x800 captures of the same synthetic page. No resizing, sharpening, or other image processing was applied. Open the images at their original size to compare small text and one-pixel lines.

   Before: inline preview visible and scaled to fit.

   

   After: same preview hidden with the native tool workaround.

   

   Verified workaround through the native tools

   preview_open({ tabId, open: false, show: false });
   // Confirm preview_status reports visible:false.
   preview_resize({ tabId, mode: 'freeform', width: 1280, height: 800 });
   // Wait for layout/fonts, then verify innerWidth/innerHeight and DPR.
   preview_snapshot({ tabId, includeImage: false, save: true });

   Keep the preview hidden through preview_recording_start / preview_recording_stop when recording. The tab stays loaded and automation remains usable.

   Separately, the installed automation-snapshot implementation caps PNG width at 1280 pixels (MAX_SCREENSHOT_WIDTH / captureAutomationSnapshot). I measured 1440x900 becoming 1280x800 and 1920x1080 becoming 1280x720. save:true preserves those already-reduced bytes. That cap explains some resolution loss, but does not explain the visible/hidden sharpness difference at the same 1280x800 dimensions.

   Standalone Chrome/Playwright also produced clear captures as a fallback. The narrow-preview transform is consistent with the existing reports, but I did not independently isolate the underlying Chromium rasterization mechanism or test the proposed fix in #9916.

   Small synthetic reproduction page

   <!doctype html>
   <meta charset="utf-8">
   <style>
     body { margin: 40px; background: white; color: #17212b; font: 16px Arial, sans-serif; }
     .lines { width: 640px; height: 40px; background: repeating-linear-gradient(90deg, #000 0px, #000 1px, #fff 1px, #fff 2px); }
   </style>
   <h1>Browser capture calibration</h1>
   <p>16px: Invoice #1042 - Screen repair - $149.00</p>
   <p style="font-size:14px">Customer details, payment status, and repair history.</p>
   <p style="font-size:12px">ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 abcdefghijklmnopqrstuvwxyz</p>
   <div class="lines"></div>

   This is a reduced version of the local calibration page used. Serve it locally and compare saved captures with the preview scaled/visible versus fully hidden, while keeping the page viewport fixed.
4. ScottN-PV commented on Oct 7, 2026

   

   ScottN-PV

   on Oct 7, 2026

   Contributor

   More actions

   Still reproduces on 0.0.46-nightly.20261006.2735 through the server capture path from #15328. Windows 11, 150% scaling, desktop app on its bundled server, agent preview_snapshot of a page with 12/14/16 px text and 1 px lines, viewport 1280×800 throughout:

   • Panel maximized: text mostly sharp, 1 px lines resampled.
   • Panel at about a third of the screen: 12 px text nearly unreadable, 16 px blurred.
   • Tab opened while the panel was hidden: it ran headless and the capture is sharp.

   Agent snapshots and recordings now run on the server over CDP (apps/server/src/preview/ServerBrowser.ts), including tabs the desktop draws. The desktop capturePage path that #9916 changes still serves the Screenshot button and annotation crops, so that PR as written does not reach preview_snapshot.

   Separately, at DPR 1.5 these PNGs are 960×600 although the viewport and the reported screenshot size are 1280×800; filed as #16690.

   Maximized	Narrow

   Written by Claude Fable 5.1 and Claude Opus 5.5 on behalf of ScottN-PV.